Stand: 01.12.2022
Arbeitsgemeinschaft der Vermessungsverwaltungen der Länder der Bundesrepublik Deutschland (AdV)
Dokumenthistorie
| Version | Stand | Bemerkung | Beteiligte |
|---|---|---|---|
7.1 |
31.07.2018 |
Korrekturen aufgrund beschlossener Tickets; Beschreibung wesentlicher Änderungen (Anwendungsschemata LB/LN) sowie Anpassung der Release Notes (in Anhang übertragen) Ergänzung von aktuellen Entwicklungen im Bereich der Qualitätssicherung |
M. Seifert, S. Schliebner, M. Indorf |
— |
18.12.2018 |
Strukturierung der Anwendungsschemata der GeoInfoDok; Umbennennung des Hauptdokumentes |
RAus, AK IK-Leiter |
— |
01.02.2019 |
Klarstellungen durch Rückmeldungn im Rahmen des Umlaufbeschlussess |
RAus |
— |
01.06.2019 |
Redaktionelle Anpassungen an neues Datenmodell; Anpassung der zusätzlichen Festlegungen zur Verwendung von GML in der NAS aufgrund der Implementierung mit der AdV-Testsuite |
RAus |
— |
10.11.2021 |
Release Notes der letzten Version aus Anhang 2 in die Dokumentstruktur übernommen. Einarbeitung sämtlicher Revisionstickets, die das Basisschema und das Gesamtkonzept betreffen. Redaktionelle Überarbeitung |
M. Seifert |
— |
17.01.2022 |
Korrekturen aufgrund der Tickets #6140, #6141, #6142, #6143, #5617 |
RAus, M.Seifert |
02.02.2022 |
Klarstellung zur Kennung AAA:Landnutzung = TRUE |
RAus, C. Lucas |
|
25.10.2022 |
Korrekturen aufgrund der Tickets #6233, #6279, #6291, #6305, #6326 |
RAus |
|
01.12.2022 |
Ergänzung im Abschnitt „Codierung von Geometrieeigenschaften in der NAS“ um Beispiel der Themendefinition aus dem BasisDLM |
RAus |
|
01.12.2022 |
Korrekturen aufgrund neuer Versionsbezeichnungen in den Anwendungsschemata; |
RAus |
Wesentliche Änderungen zur Vorgängerversion (Release Notes)
Diese Release Notes richten sich an Primärdatenanbieter und Entwickler, die Daten nach Implementierung einer neuen Referenzversion im alten Verfahren abgeben wollen. Sie enthalten die Beschreibung ausgewählter Änderungen der neuen Version und sollen die Implementierung der neuen Version erleichtern. Die Release Notes der jeweiligen Vorgängerversionen ist in Anhang 2 enthalten - TBD: Referenz korrigieren..
Neue Attributart "QuellobjektID" bei der Objektart "AA_Objekt"
Der Datenaustausch zwischen dabag und ALKIS (und LEFIS) ist ein fundamentaler Baustein der digitalen Zukunft im AAA-Umfeld, hierzu wird es notwendig, eine performante Verbindung zwischen der Objekt-ID im AAA und den verwendeten IDs in den Quellsystemen (dabag und LEFIS) zu nutzen.
Der bisherige favorisierte Ansatz, den Objektidentifikator eines Quellsystems in einer Fachdatenverbindung zu speichern, zielt prinzipiell auf die Speicherung von identifizierenden Merkmalen zugehöriger Objekte in einem beliebigen Fremdsystem, so dass das oder die zugehörigen Objekte dort gefunden werden können. Aufgrund von Implementierungstests für den Datenaustausch zwischen dem Datenbankgrundbuch (dabag) und ALKIS erwies sich so ein komplexes Element wie die Fachdatenanbindung, die zudem auch für eine Reihe von anderen Refererenzen verwendet wird, als nicht performant genug für den gegenseitigen Datenaustausch. Daher wurde die Objektart "AA_Objekt" um ein Attribut "quellobjektID"erweitert.
Anwendungsschemata Landbedeckung und Landnutzung
Eine wesentliche Erweiterung der GeoInfoDok sind die Anwendungsschemata zu Landnutzung (LN) und Landbedeckung (LB). Diese sind eigene Anwendungsschemata außerhalb des AAA-Anwendungsschemas, somit lassen sie sich unabhängig davon implementieren.
Dennoch bestehen modellierungstechnische Abhängigkeiten zum AAA-Anwendungsschema (z.B. AAA-Basisschema). Da die Objektarten der Landnutzung aus den flächenförmigen Objektarten der TN sowie flächenförmigen Objekten weiterer Objektartenbereiche (50000, 60000, 70000) durch eine Schematransformation erzeugt werden und die Objektarten der Landbedeckung in erster Linie aus Fernerkundungsdaten erzeugt werden, wurden zwei getrennte Anwendungsschemata angelegt. Zur Schematransformation der Objektarten der Landnutzung wurden notwendige Anpassungen an den bestehenden Objektarten der Tatsächlichen Nutzung vorgenommen.
Beide Anwendungsschemata wurden jedoch extern modelliert, damit das AAA-Anwendungsschema weitgehend unverändert und stabil bleibt, andererseits aber auch dem Grundsatz der Modularisierung Rechnung getragen wird, um eine getrennte und flexible Fortführung der Module zu erlauben.
Für die Elemente der Landbedeckung und Landnutzung wurde eine weitere Standardmodellart "GeoBasis-DE" ergänzt. Zudem wurde ein neuer Tagged Value "AAA:Landnutzung = TRUE" eingeführt, welcher die Wertearten markiert, die für eine konfliktfreie und semantisch eindeutige automatisierte Ableitung der Landnutzung (LN) zwingend zu erheben sind. Damit kommt dem Tagged Value die Funktion des Grunddatenbestandes (G) gleich, zumindest für die Modellartenkennung, aus der die Landnutzung primär abgeleitet wird. Die Information wird in den abgeleiteten Objektkatalogen als Ergänzung "(LN)" bei den Wertearten mit ausgegeben. Welche Attribut- und Wertearten darüber hinaus für die vollständige automatisierte Ableitung der Landnutzung erforderlich sind, wird durch die Mappingregeln der Migrations-Mapping-Tabelle ausgesagt.
Hinweis für die Migration von GeoInfoDok 6 nach dem AAA-Anwendungsschema 7.1.2:
Die Attributarten 'ErgebnisDerUeberpruefung (EDU)' bzw. 'DatumDerLetztenUeberpruefung (DLU)' dürfen im Rahmen der Migration nicht belegt bzw. geändert werden, da es sich nicht um pauschale Annahmen, sondern zukünftig um Metadaten zur Qualifizierung der Daten handeln soll. Die Belegung von EDU und DLU wird in den Erläuterungen zur Tatsächlichen Nutzung und zur Landnutzung beschrieben.
Anwendungsschema Geometrische Verbesserung
Dieses Anwendungsschema enthält für ein Verfahrensgebiet (Homogenisierungsgebiet) die Verschiebungsvektoren in der Form, dass alle Positionen der Ausgangskoordinaten und die Positionen der Endkoordinaten mit dem Hinweis auf Verwendung als Stützpunkt gespeichert und übergeben werden können.
Dieses Anwendungsschema ist fachlich völlig unabhängig vom AAA-Anwendungsschema, bezieht sich aber auf dieselben Basisklassen des AAA-Basisschemas. Auch dieses Anwendungsschema wurde daher extern modelliert, damit die Führung dieser Informationen optional möglich ist.
Für die Elemente des Anwendungsschemas Geometrische Verbesserung wurde eine weitere Standardmodellart "GVM" eingeführt.
Optionale Führung der Objektart "Historisches Flurstück" auch bei Vollhistorie
Bislang wurde im Anwendungsschema nicht zwischen aktuellen und historischen Daten unterschieden, d.h. bei der Vollhistorie werden keine eigenen historischen Objektarten gebildet. Dieser Grundsatz wurde gestrichen, da das "Historische Flurstück" mit seinen abgeleiteten Inhalten für die Daten-führende Stellen, die die Vollhistorie führen, und auch für deren Nutzer einen großen Mehrwert darstellt, da es:
-
die Informationsmenge so bündelt, wie es viele Anwender benötigen,
-
die Performance bei der Bereitstellung der Informationen erheblich steigert und somit
-
die Flexibilität der Nutzung wesentlich erhöht.
In den bekannten realisierten Datenhaltungskomponenten wird das "Historische Flurstück" heute grundsätzlich geführt, so dass keine zusätzlichen Implementierungsaufwände entstehen. Auf die anderen bereits im ALB historisch gewordenen Flurstücke hat die Streichung des Grundsatzes keine Auswirkung, da diese nach deren Migration nicht mehr neu entstehen.
Codierung von Zeilenumbrüchen
Der AdV-SK spricht an einer Stelle bei der Präsentation von einem \n (newline):
Bisher war unklar wie der Zeilenumbruch in XML, z.B. in der NAS, codiert werden soll, was zu unterschiedlichen und damit nicht interoperablen Umsetzungen geführt hat.
Gelöst wurde dies nun, indem im Schriftinhalt eines Präsentationsobjektes durch ein entsprechendes LF-Zeichen "\n" angegeben werden muss, das ein Steuerzeichen darstellt und nicht in der Ausgabe darzustellen ist. In XML wird ein LF durch ein Zeichen - typischerweise #xA - repräsentiert.
Realisierung einer Testkomponente für Daten der GeoInfoDok
Zur Gewährleistung der fach- und stellenübergreifenden Interoperabilität müssen die von den AdV-Mitgliedsverwaltungen geführten Geobasisdaten anhand der abgestimmten AAA-Datenmodelle in den jeweils gültigen Versionen geprüft werden. Die Interoperabilität ist die Voraussetzung, dass die Geobasisdaten bundesweit einheitlich von den Nutzern in ihren Geoinformationssystemen verwendet werden können. Die AdV-Spezifikationen bilden den Maßstab der Datenqualitätsprüfungen.
Damit die jeweiligen AdV-Mitgliedsverwaltungen ihre Daten prüfen können, wird eine geeignete Testplattform (AdV-Testsuite) aufgebaut. Dabei geht es nicht um eine offizielle Zertifizierung, sondern um den technischen Vorgang zur Überprüfung von Anforderungen aus AdV-Spezifikationen als Teil einer umfassenden Qualitätssicherung der amtlichen Geobasisdaten. Die AdV-Testsuite wird zunächst für Datentests der GeoInfoDok entwickelt, die Konformitätstests für die AdV-Diensteprofile und Metadaten erfolgt in späteren Realisierungsschritten. Neben der Testplattform wird auch eine Registry zur Erfassung und Pflege der Testkriterien entwickelt. Ausführliche Erläuterung dazu sind in Kapitel 9 zu finden.
Implizite Funktionalitäten
Bei der Führung von Primär- und Sekundärnachweisen über die Schnittstelle NAS ist es erforderlich, dass das aufnehmende System neben der Ausführung der expliziten Funktionen <Insert>, <Delete> und <Replace> auch über implizite Funktionen verfügt, die erst die komfortable Arbeitsweise mit dem System erlauben.
Eine aktualisierte Tabelle mit einer Zusammenstellung dieser Funktionen bezogen auf die verschiedenen Fachobjekte wurde in Anhang A ergänzt.
Versionierung der Anwendungsschemata
Durch die Modularisierung der AdV-Datenmodelle hat sich eine Änderung der Bedeutung der GeoInfoDok ergeben. Bisher wurde die GeoInfoDok gleichgesetzt mit dem AAA-Anwendungsschema und dem Hauptdokument. Künftig bezieht sich die GeoInfoDok - wie ursprünglich auch beabsichtigt - auf sämtliche Modellierungen der Daten des amtlichen Vermessungswesens, also auch Anwendungsschemata außerhalb des AAA_Anwendungsschemas (z.B. LB, LN). Derzeit umfasst die GeoInfoDok folgende Modularten:
-
AFIS-ALKIS-ATKIS Anwendungsschema als zentrales Datenmodell der AdV
-
externe Datenmodelle mit Bezug zum AAA-Anwendungsschema, z.B. zur Landbedeckung und Landnutzung
-
Module mit beschreibendem Charakter (Metamodelle), z.B. AAA_Signaturenkatalog.
Das Hauptdokument in seiner bisherigen Form definiert Modellierungsgrundsätze und technische Grundlagen für sämtliche Module, kann sich also nicht nur alleine auf die eine bestimmte Version des AAA-Anwendungsschemas beziehen. Daher wird es künftig auch nicht mehr als "Hauptdokument", sondern als "Gesamtkonzept" bezeichnet. Zudem entfällt damit auch die Versionsnummer, da dieses Dokument nun keinen exklusiven Bezug mehr zum AAA-Anwendungsschema hat. Das Dokument "Gesamtkonzept" trägt künftig nur noch eine Datumsangabe. Das Gesamtkonzept kann, wie die externen Datenmodelle, auch unabhängig vom AFIS-ALKIS-ATKIS-Anwendungsschema fortgeführt und veröffentlicht werden. Das Gesamtkonzept ist Teil der GeoInfoDok, die nun auch nicht mehr analog zum AAA-Anwendungsschema versioniert werden muss.
Das Gesamtkonzept beschreibt jedoch nach wie vor auch das Basisschema und die NAS als zentrale und fachneutrale Bausteine für beliebige Anwendungsschemata innerhalb und außerhalb des amtlichen Vermessungswesens, was derzeit Teil des AFIS-ALKIS-ATKIS-Anwendungsschemas ist und auch bleibt. Es ist somit stets im Gesamtkonzept anzugeben, welche Version des Basisschemas jeweils spezifiziert wird. Für dieses Dokument ist es die Version 7.1.2.
Die GeoInfoDok besteht damit aus dem Gesamtkonzept (diesem Dokument) sowie den folgenden darauf aufbauenden Anwendungsschemata, bzw. Modulen:
Zentrales Anwendungsschema ist das AFIS-ALKIS-ATKIS Anwendungsschema, u.a. mit dem AAA_Basisschema und dem AAA_Fachschema, die oft als Grundlage für weitere Anwendunsschemata der AdV oder auch außerhalb der AdV (z.B. LEFIS) verwendet wird.
Durch den modularen Aufbau der GeoInfoDok können Schemata (=Module) auch außerhalb dieses zentralen AAA_Anwendungsschemas beschrieben und getrennt davon fortgeführt werden. Besteht eine logische Abhängigkeit der Module vom AAA-Anwendungsschema, ist in einem entsprechenden Tagged Value (AAA:AAAVersion) die Version des AAA-Anwendungsschemas anzugeben, auf das das jeweilige Modul aufbaut.
Die Module selbst werden unabhängig vom AAA-Anwendungsschema versioniert und beginnen einheitlich ab der Veröffentlichung dieses Gesamtkonzeptes mit der Version 1.0.0, es sei den, ein Modul folgt schon dieser Logik. In diesem Fall wird dann die schon vorhandene Versionsnummer weiterverwendet. Dies betrifft derzeit nur das SK-Objektmodell.
Die sogenannte AdV-Referenzversion bezieht sich nach wie nur auf die entsprechende Version des AAA-Anwendungsschemas.
Modulare Strukturen und ihre Versionsbezeichnungen
Die GeoInfoDok enthält verschiedene Anwendungsschemata, die jeweils eigenständig versioniert werden. Aktuell gilt das Gesamtkonzept für folgende Module:
-
AFIS-ALKIS-ATKIS Anwendungsschema in der Version 7.1.2 (AdV-Referenzversion 7.1) mit dem AAA Fachschema, AAA Basisschema, AAA Versionierungsschema und NAS-Operationen.
-
Landnutzung in der Version 1.0.2 - "LN-Anwendungschema-1.0.2_referenziert_7.1.2", bedeutet, dass das LN-Anwendungsschema 1.0.2 Elemente aus dem AFIS-ALKIS-ATKIS Anwendungsschema in der Version 7.1.2, hier insbesondere AAA Basisschema, AAA Versionierungsschema und NAS-Operationen, verwendet.
-
Landbedeckung in der Version 1.0.1 - "LB- Anwendungschema-1.0.1_referenziert_7.1.2"
-
Geometrische Verbesserungen in der Version 1.0 - "GV- Anwendungschema-1.0.0_referenziert_7.1.2"
-
AFIS-ALKIS-ATKIS_Ausgabekatalog in der Version 2.0.0 - "AAA-AK-2.0.0_referenziert_7.1.2"
-
Metamodelle für
-
AAA-Objektartenkatalog in der Version 1.0.0 - "AAA-OK-1.0.0"
-
AAA-Signaturenkatalog in der Version 2.0.0 - "AAA_Signaturierung-2.0.0"
-
Diese Übersicht wird nach Einführung neuerer Versionen aktualisiert.
Normative Referenzen
Die folgenden referenzierten Dokumente sind für die Implementierung des AAA-Anwendungsschemas unabdingbar. Für Quellen mit Datumsangabe gilt nur diese eine genannte Version. Für Quellen ohne Datumsangabe gilt immer die letzte veröffentlichte Version einschließlich eventueller Überarbeitungen.
-
ISO/IEC 19501:2005, Unified Modeling Language Specification (UML), http://www.uml.org/
-
XML 1.0, 5th Edition, Extensible Markup Language (XML), W3C Recommendation, 26 November 2008, http://www.w3.org/TR/2008/REC-xml-20081126/
-
XML Schema Part 1, 2nd Edition: Structure-W3C Recommendation, 28. Oktober 2004, http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/
-
XML Schema Part 2, 2nd Edition: Datatypes-W3C Recommendation, 28. Oktober 2004, http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/
-
XLink XML Linking Language (XLink) Version 1.1, W3C Recommendation 06 May 2010, http://www.w3.org/TR/2010/REC-xlink11-20100506/
-
OGC Web Feature Service 2.0 Interface Standard - With Corrigendum, Open Geospatial Consortium, 2014, http://docs.opengeospatial.org/is/09-025r2/09-025r2.html
-
Die Version 2.0.0 dieses Standards ist als ISO 19142 veröffentlicht.
-
-
OGC Web Services Common Specification 1.1.0 with Corrigendum 1, Open Geospatial Consortium, 2007, http://portal.opengeospatial.org/files/?artifact_id=20040
-
OGC Filter Encoding 2.0 Encoding Standard - With Corrigendum, Open Geospatial Consortium, 2014, http://docs.opengeospatial.org/is/09-026r2/09-026r2.html
-
Die Version 2.0.0 dieses Standards ist als ISO 19143 veröffentlicht.
-
-
OpenGIS Implementation Specification for Geographic information - Simple feature access - Part 2: SQL option, Version 1.2.1, Open Geospatial Consortium, 2010, http://portal.opengeospatial.org/files/?artifact_id=25354
-
OGC Geography Markup Language (GML) - Extended schemas and encoding rules, Version 3.3, Open Geospatial Consortium, 2012, https://portal.opengeospatial.org/files/?artifact_id=46568
-
Dieser Standard wurde 2015 als ISO 19136-2 veröffentlicht.
-
-
OGC GML Application Schema - Coverages, Version 1.0.1, Open Geospatial Consortium, 2012, https://portal.opengeospatial.org/files/?artifact_id=48553
-
Dieser Standard soll zukünftig als ISO 19123-2 veröffentlicht werden.
-
-
XML Path Language (XPath) Version 1.0, W3C Recommendation 16. November 1999, http://www.w3.org/TR/1999/REC-xpath-19991116/
-
ISO - ISO 19103:2015 - Geographic information — Conceptual schema language
-
ISO - ISO 19107:2019 - Geographic information — Spatial schema
-
ISO - ISO 19109:2015 - Geographic information — Rules for application schema
-
ISO - ISO 19110:2016 - Geographic information — Methodology for feature cataloguing
-
ISO - ISO 19111:2019 - Geographic information — Referencing by coordinates
-
ISO - ISO 19115-1:2014 - Geographic information — Metadata — Part 1: Fundamentals
-
ISO - ISO 19123:2005 - Geographic information — Schema for coverage geometry and functions
-
ISO - ISO 19127:2019 - Geographic information — Geodetic register
-
ISO - ISO/TS 19139:2007 - Geographic information — Metadata — XML schema implementation
-
ISO - ISO 19157:2013 - Geographic information — Data quality
-
[KOSIT-01]: Koordinierungsstelle für IT-Standards (KOSIT), "Zeichen und definierte Zeichensequenzen in Unicode für die elektronische Verarbeitung von Namen und den Datenaustausch in Europa", DIN 91379, (2022), GitHub - String-Latin/DIN-91379-Characters-and-Sequences: List of characters and sequences of DIN 91379
1. Aufbau, Inhalt und Ziel
1.1. Ausgangssituation, Motive und Zielvorstellung
Die Vermessungs- und Katasterverwaltungen der Bundesländer haben die Aufgabe, raumbezogene Basisdaten (Geobasisdaten) für Verwaltung, Wirtschaft und private Nutzer zu liefern, und zwar zunehmend in digitaler Form. Hierauf wurde bereits sehr früh reagiert und begonnen, die Daten des Liegenschaftskatasters in den Projekten ALK (Automatisierte Liegenschaftskarte) und ALB (Automatisiertes Liegenschaftsbuch) sowie die Daten der Topographischen Landesaufnahme im Projekt ATKIS (Amtliches Topographisch-Kartographisches Informationssystem) deutschlandweit einheitlich digital zu erfassen und zur Verfügung zu stellen. In den meisten Bundesländern wurde durch Kabinettsbeschluss geregelt, dass die ALK-, ALB- und ATKIS-Daten als Basis für andere Fachinformationssysteme (FIS) zu verwenden sind.
Die Konzepte, nach denen ALB, ALK und ATKIS aufgebaut worden sind, stammen aus den 70er bzw. 80er Jahren des 20. Jahrhunderts. Außerdem wurden daneben weitere umfangreiche digitale Datenbestände nach jeweils eigenen Konzepten der Bundesländer aufgebaut, z. B. Digitale Orthophotos, Rasterdaten der topographischen Landeskartenwerke und Digitale Höhenmodelle.
Vor dem Hintergrund der sich schnell entwickelnden Technik, der inzwischen umfangreichen Erfahrungen der Hersteller bei der Datenerfassung und den sich aus der Datennutzung ergebenden veränderten Anforderungen seitens der Anwender war es erforderlich, diese Konzepte zu überprüfen und weiterzuentwickeln.
Die bisherigen Informationssysteme ALK und ALB werden deshalb zukünftig integriert im Informationssystem ALKIS (Amtliches Liegenschaftskatasterinformationssystem) geführt, dabei wird auch die Weiterentwicklung zu 3D-Geobasisdaten aufgegriffen. Insbesondere bei den Gebäuden in ALKIS besteht der Bedarf, optional auch 3D-Informationen abzulegen zu können. Darüber hinaus wurde eine formelle, inhaltliche und semantische Harmonisierung mit ATKIS vorgenommen.
Die Digitalen Geländemodelle (DGM) werden in ATKIS nicht wie bisher im Objektbereich Relief einem spezifischen Digitalen Landschaftsmodell (DLM) zugeordnet, sondern als eigenständiger Bestandteil unter den objektstrukturierten Daten ausgewiesen. Hiermit wird, ähnlich wie den Festpunkten der Grundlagenvermessung, die universelle Verwendbarkeit des DGM als eigenständiger Datenbestand verdeutlicht und die Möglichkeit zur Erzeugung von kombinierten Datenbeständen oder Erzeugnissen unter Verwendung von Daten aus anderen Produktgruppen besser herausgestellt.
Für die Digitalen Orthophotos (DOP) liegt ein AdV-Standard vor, der zwar nach bisherigem Verständnis keine Anwendung des gemeinsamen Anwendungsschemas ist, der aber trotzdem in die Gesamtdokumentation unter der Überschrift Bildstrukturierte Daten im Kapitel 2, Das AFIS-ALKIS-ATKIS-Referenzmodell aufgenommen wird.
Die Ableitung von 3D-Stadt- und Landschaftsmodellen aus den Geobasisdaten wird durch die Kombination von 3D-Informationen in ALKIS und den DGM in ATKIS sowie der Geländetexturierung mit DOP ermöglicht.
Zur Nutzung der für den 2D-Bereich definierten Eigenschaften von Geoinformationssystemen wurden die Basisklassen für die Modellierung von 3D-Informationen in das Basisschema integriert. Dadurch könnten die ALKIS - Fortführungsprozesse auch zur wirtschaftlichen Fortführung der 3D - Geobasisdaten genutzt werden.
Zu den Geoinformationen des amtlichen Vermessungswesens gehören auch die Informationen zu den Festpunkten. Da die Festpunkte originär weder zur ALK noch zu ATKIS gehören, wird deren Modellierung nunmehr in einem eigenen Informationssystem Amtliches Festpunktinformationssystem (AFIS) durch einen eigenen Objektartenkatalog vorgenommen.
Unter der Überschrift Dokumentation zur Modellierung der Geoinformationen des amtlichen Vermessungswesens werden die AdV-Projekte AFIS, ALKIS und ATKIS mit ihren länderübergreifend festgelegten Eigenschaften in durchgängiger Form gemeinsam beschrieben. Sie werden in einem gemeinsamen Referenzmodell miteinander in Beziehung gebracht und im Rahmen dieser Dokumentation in den weiteren Kapiteln als gemeinsames Anwendungsschema für AFIS, ALKIS und ATKIS beschrieben.
Das gemeinsame Anwendungsschema sieht die Erfassung und Führung von Metadaten und Qualitätsdaten gemäß der ISO-Spezifikationen vor.
1.2. Grunddatenbestand, Objektartenkataloge und Versionierung
Grunddatenbestand ist der von allen Vermessungsverwaltungen der Länder der Bundesrepublik Deutschland in AFIS, ALKIS und ATKIS bundeseinheitlich zu führende und dem Nutzer länderübergreifend zur Verfügung stehende Datenbestand. Dazu gehören auch die entsprechenden Metadaten. Eine spätere Erweiterung des Grunddatenbestandes ist zu erwarten.
Die Objektartenkataloge des Liegenschaftskatasters und der Landesvermessung wurden im Interesse einer möglichst einheitlichen Realweltmodellierung soweit möglich und sinnvoll semantisch harmonisiert. Die Harmonisierung hat sowohl Vorteile für die interne Nutzung als auch im externen Bereich. Sie orientiert sich an den bisherigen Katalogen (Muster-OBAK, Verzeichnis der Nutzungsarten, ATKIS-OK).
Im Zusammenhang mit der Beschreibung des Verfahrens zur Nutzerbezogenen Bestandsdatenaktualisierung (NBA) wird ein Versionskonzept eingeführt. Länder, die eine Historienverwaltung im Sinne der von der AdV beschlossenen Stufenlösung für ALKIS einsetzen, legen ihrer Modellierung und den darauf basierenden Funktionalitäten einer Historienverwaltung genau dieses um das Versionskonzept erweiterte Anwendungsschema zu Grunde. Hinsichtlich der Historienverwaltung wird für ATKIS die stichtagsbezogene Speicherung der jeweiligen Datenbestände für ausreichend erachtet.
Mit der Integration von 3D-Informationen in das gemeinsame Anwendungsschema für AFIS, ALKIS und ATKIS ist auch der Bedarf nach einem Versionierungs- und Historisierungskonzept für 3D-Geobasisdaten abgedeckt.
1.3. Zielgruppe und Nutzer
Überregionale Nutzer und GIS-Industrie fordern im Hinblick auf die Inhalte und die Strukturierung der Geobasisdaten sowie aus Gründen der Wirtschaftlichkeit die Festlegung eines bundesweit einheitlichen Grunddatenbestandes. Aus der ganzheitlichen Sicht auf das amtliche Vermessungswesen sollen die Grunddatenbestände von AFIS, ALKIS und ATKIS zu diesem Grunddatenbestand der Geodaten des amtlichen Vermessungswesens zusammengeführt werden.
Mit der Europäischen Rahmenrichtlinie zum Aufbau einer Geodateninfrastruktur in Europa INSPIRE kommt der standardkonformen Modellierung von Geobasisdaten eine wesentliche Rolle zu. Ein zentrales Ziel von INSPIRE ist die Bereitstellung von mehr und vor allem einheitlichen Geodaten für die Gemeinschaftspolitik und deren Umsetzung in den Mitgliedstaaten auf sämtlichen Ebenen. Der Schwerpunkt liegt dabei auf der Umweltpolitik. In einer europäischen Geodateninfrastruktur können die verschiedenen Geodaten selbst innerhalb einer Fachverwaltung durchaus einen unterschiedlichen Harmonisierungsgrad aufweisen. INSPIRE enthält deshalb drei verschiedene Anhänge, die sich auf unterschiedliche Themenbereiche von Geodaten beziehen, die für einen breiten Bereich umweltpolitischer Maßnahmen erforderlich sind. Je nachdem, ob Geodaten für die Georeferenzierung anderer Daten verwendet werden oder harmonisierte Geodaten für politische Maßnahmen mit direkten oder indirekten Auswirkungen auf die Umwelt erforderlich sind, und je nach Harmonisierungsgrad, der in der Gemeinschaft bereits erreicht ist, gelten unterschiedliche Zielfristen für die Erfüllung der Anforderungen von INSPIRE sowie unterschiedliche Harmonisierungsvorgaben. Wie diese Geodaten organisiert und harmonisiert werden sollen wird nicht hier, sondern in den technischen Ausführungsbestimmungen geregelt.
Durch INSPIRE wird kein umfassendes Programm zur Erfassung neuer Geodaten in den Mitgliedstaaten geschaffen. Stattdessen wird die Dokumentierung vorhandener Geodaten verlangt, um die Nutzung bereits verfügbarer Daten zu optimieren. Dafür werden Dienste (Web Services) festgelegt, die Geodaten besser zugänglich und interoperabel machen, und es wird versucht, Probleme bei der Nutzung von Geodaten zu lösen (Zugriffsrechte, Preise etc.). INSPIRE wird somit den Weg zu einer schrittweisen Harmonisierung von Geodaten in den Mitgliedstaaten ebnen. Mit dem AFIS-ALKIS-ATKIS-Anwendungsschema ist die AdV schon hinreichend für die INSPIRE-konforme Datenabgabe vorbereitet.
Die GIS- und CAD-Anwender haben ferner großes Interesse am Aufbau eines auf den Daten des amtlichen Liegenschaftskatasters aufbauenden 3D - Modells, um ihre Planungen auf dieser amtlichen Grundlage darstellen und besser visualisieren zu können. Des Weiteren finden die anfallenden 3D - Informationen in einem auf der GeoInfoDok basierenden, einheitlichen 3D - Modell eine geeignete Plattform zur Speicherung. Derzeit gibt es für diese Informationen keinen amtlichen Nachweis.
Die EU-Richtlinie zur Minderung von Umgebungslärm (2002/49/EG) verpflichtet zukünftig zu regelmäßigen detaillierten Lärmausbreitungsberechnungen, die nur auf der Grundlage von stetig fortgeführten 3D-Stadtmodellen erfolgen können. Auf der GeoInfoDok aufbauende 3D-Informationen bieten die Grundlage zur Ermittlung der Umgebungslärmdaten, bieten Fortführungsmechanismen und ermöglichen die geforderte turnusmäßige Überprüfung der Lärmkartierungen durch die Nutzung des Versionierungs-/Historisierungskonzeptes.
Für die Migration aus den bisherigen Nachweisen ist ein grundsätzliches Vorgehen in Form eines Stufenkonzeptes vorgesehen. Die Detailausarbeitung von Migrationskonzepten ist länderspezifisch auszuführen. Eine Rückmigration in die Schnittstellen der bisherigen Systeme für eine übergangsweise Versorgung der Nutzer mit Daten ist noch für einen längeren Übergangszeitraum denkbar. Das Migrationskonzept besitzt nur temporäre Bedeutung und wird deshalb nicht in die Gesamtdokumentation aufgenommen.
2. Das AFIS-ALKIS-ATKIS-Referenzmodell
Das AFIS-ALKIS-ATKIS-Referenzmodell hat die Aufgabe, die nach dieser Dokumentation beschriebenen Datenbestände mit ihren Beziehungen im Kontext darzustellen. Ziel dabei ist es,
-
Komponenten zu identifizieren,
-
die Modularisierung zu erleichtern,
-
die Verbindung zu den Normen aufzuzeigen und
-
Doppelarbeit innerhalb der Komponenten zu vermeiden.
AFIS ist das Amtliche Festpunktinformationssystem und enthält beschreibende und darstellende Daten zu folgenden Produktgruppen:
-
AFIS-Bestandsdaten,
-
digitale AFIS-Auszüge sowie
-
analoge AFIS-Auszüge.
ALKIS ist das Amtliche Liegenschaftskatasterinformationssystem und enthält liegenschaftsbeschreibende und -darstellende Daten in folgenden Produktgruppen:
-
ALKIS-Bestandsdaten (optional auch Erweiterung um 3D-Informationen),
-
digitale ALKIS-Auszüge sowie
-
analoge ALKIS-Auszüge.
ATKIS ist das Amtliche Topographisch-Kartographische Informationssystem der deutschen Landesvermessung. ATKIS beschreibt die Landschaft mit unterschiedlichen Anwendungszielen in folgenden Produktgruppen:
-
digitale Landschaftsmodelle (ATKIS-DLM und Zusatzdaten) einschließlich digitaler Geländemodelle (DGM),
-
digitale topographische Karten (DTK),
-
analoge Auszüge aus den DTK (Topographische Karten) sowie
-
digitale Bildmodelle (DBM) in Form digitaler Orthophotos (DOP).
Die Inhalte, Strukturen und Herstellungsvorschriften der Produkte des Referenzmodells werden auf der Regelungsebene durch die Objektartenkataloge (OK) und Signaturenkataloge (SK) definiert. Diese umfassen:
-
Vorschriften zur Abbildung der Informationen der Festpunkte, des Liegenschaftskatasters und der Topographie,
-
Vorschriften zur Bildung von Präsentations- und Kartengeometrieobjekten (Zusatzdaten),
-
Vorschriften zur Darstellung und kartographischen Gestaltung der Objekte,
-
Vorschriften zur Ausgestaltung von analogen Auszügen.
Die Erfassungsvorlagen in der Produktionsebene sind untergliedert in Landschaft, digitale Bildmodelle (digitale Orthophotos) sowie Karten und andere Unterlagen. Die Landschaft als Quelle der Originalinformation wird insbesondere im Rahmen der Fortführung als Erfassungsquelle herangezogen werden. Durch den digitalen Datenfluss fließen im Felde registrierte Daten ohne den Umweg über analoge Medien direkt oder nach Strukturierung und Klassifizierung in die Bestandsdaten von AFIS, ALKIS und ATKIS ein. Die aufgebauten Geobasisdatenbestände können zugleich wieder als Erfassungsquelle für abgeleitete Datenbestände dienen, z.B. sind Teile der ALKIS-Bestandsdaten, insbesondere die Gebäudedaten, Grundlage zur Ableitung entsprechender Daten für das ATKIS-DLM. Der Erfassungsvorgang umfasst auch die Bildung von Präsentations- und Kartengeometrieobjekten und schließt damit auch den Vorgang der kartographischen Generalisierung ein.
Die Bestandsdaten unterscheiden sich durch den Abstraktionsgrad, mit dem sie die Erdoberfläche und damit in Beziehung stehende Sachverhalte modellieren. Sie weisen Eigenschaften wie Objektstrukturierung und Geokodierung auf. Sie enthalten neben den Fachobjekten mit ihren semantischen und geometrischen Informationen auch die zur Präsentation benötigten Daten:
-
nämlich die Präsentationsobjekte für Text und Signaturen
-
sowie die mit den topographischen Objekten durch eine einseitige Relation verknüpften Kartengeometrieobjekte mit der jeweiligen Kartengeometrie für einen bestimmten Kartenmaßstab.
Die Bestandsdaten enthalten damit die vollständige Beschreibung von Fachobjekten einschließlich der Daten zu ihrer kartographischen oder textlichen Darstellung in einem oder mehreren Zielmaßstäben. Damit sind die Bestandsdaten so modelliert, dass sie bei der Präsentation vollständig automatisch, d.h. ohne weiteren interaktiven Eingriff, in der vorgesehenen Ausgabeform dargestellt werden können.
An den Nutzer werden auf der Kommunikationsebene objekt- oder bildstrukturierte Daten, aufbereitete Informationen oder analoge Auszüge abgegeben, die den kompletten Dateninhalt, beliebige Auszüge nach Inhalt und Gebiet sowie Fortführungsdaten beliebiger Zeiträume umfassen können.
3. Das konzeptuelle Modell des AAA-Basisschemas
3.1. Grundsätze der Modellierung
3.1.1. Normen und Standards
Internationale Normungs- bzw. Standardisierungsaktivitäten im Bereich von Geoinformationen erfolgen zurzeit in folgenden Gremien:
-
ISO/TC 211 Geographic Information/Geomatics
-
Open Geospatial Consortium (OGC)
Ziel ist die Schaffung von Grundlagen für die gemeinsame, ganzheitliche und fachübergreifende Nutzung von Geodaten an verschiedenen Orten durch Personen, Anwendungen und Systeme auf der Grundlage einer einheitlichen Beschreibung der Inhalte vorhandener oder geplanter Datenbestände, der Funktionalitäten der Datenbearbeitung und der Kommunikation. Der Modellierung liegen die Ergebnisse des ISO/TC 211 in Form der Normfamilie 19100 im aktuellen Bearbeitungsstand zu Grunde. Im Bereich der Datenaustauschschnittstelle werden darüber hinaus auch Teile der Spezifikationen des OGC verwendet. Für die Integration von 3D-Informationen bildet CityGML (OGC Best Practices Document in der Version 0.4.0) die Grundlage.
3.1.2. Modellierungs- und Beschreibungssprache
Zur Beschreibung des Anwendungsschemas und der Objektartenkataloge hat sich die AdV entschieden, die Datenmodellierungssprache Unified Modeling Language (UML) zu verwenden. Sie wird auch von ISO/TC 211 im Bereich der Normung von Geoinformationen eingesetzt.
UML wurde von der Object Management Group (OMG) zur Beschreibung von Anwendungsschemata entwickelt. Semantik und Notation von UML sind im UML Notation Guide beschrieben. Um eine einheitliche Nutzung von UML im Bereich der Normfamilie 19100 zu gewährleisten, ist deren Anwendung in der ISO-Spezifikation 19103 Conceptual schema language festgelegt. Der Zweck liegt in der vollständigen und unzweifelhaft interpretierbaren, formalen Beschreibung von Inhalt und Struktur von Datenbeständen. Die Beschreibung ist unabhängig von der Art der Implementierung und der verwendeten Programmiersprache. Mit formalen Sprachen ist eine einheitliche Beschreibung aller Geodaten erreichbar. Die so beschriebenen Anwendungsschemata können von geeigneten Programmen automatisch interpretiert und in interne Datenstrukturen bzw. Datenbankstrukturen übersetzt werden.
Ein universelles und systemunabhängiges Datenaustausch- bzw. Dateiformat ergibt sich daraus automatisch in Verbindung mit sogenannten Kodierungsregeln. Diese Kodierungsregeln werden entsprechend der ISO-Normen 19118 Encoding und 19136 Geography Markup Language (GML) erstellt. Als Format wird die Auszeichnungssprache XML (Extensible Markup Language) des World-Wide-Web Consortiums (W3C) verwendet.
3.2. Aufgabe und Struktur
Ein Anwendungsschema liefert die formale Beschreibung für Datenstrukturen und Dateninhalte in einer oder mehreren Anwendungen. Es enthält die vollständige Beschreibung eines Datenbestandes und kann neben den geographischen auch weitere dazugehörige Daten enthalten. Ein grundsätzliches Konzept, die reale Welt zu abstrahieren, ist die Einführung des Fachobjekts und von Regeln, wie es erfasst und fortgeführt wird. Die Klassifizierung der Fachobjekte erfolgt nach Typen. Auf der Typenebene beschreibt das Anwendungsschema die Objektarten der realen Welt. Daten selbst existieren auf der Instanzenebene. Sie stellen einzelne Exemplare einer Objektart in der realen Welt dar und können durch das Anwendungsschema interpretiert werden, siehe hierzu auch ISO 19101 Reference model und 19109 Rules for application schema.
Der Zweck eines Anwendungsschemas ist es, ein gemeinsames und einheitliches Verständnis der Daten zu erreichen und die Dateninhalte für eine bestimmte Anwendungsumgebung so zu dokumentieren, dass eindeutige Informationen über die Daten erhalten werden.
Das gemeinsame AFIS-ALKIS-ATKIS-Anwendungsschema bietet einen einheitlichen und objektorientierten Modellansatz für AFIS, ALKIS und ATKIS, der möglichst mit den marktüblichen und dem Stand der Technik entsprechenden GIS-Programmen abgebildet und geführt werden soll.
Ein Anwendungsschema kann Festlegungen aus verschiedenen Subschemata verwenden. Im Fall des AFIS-ALKIS-ATKIS-Anwendungsschemas werden hauptsächlich Subschemata aus der Normfamilie ISO 19100 verwendet. In Bereichen, in denen ISO bisher keine Festlegungen getroffen hat, werden zusätzlich Schemata des Open Geospatial Consortiums verwendet.
Das AFIS-ALKIS-ATKIS-Anwendungsschema gliedert sich in das
-
AAA-Basisschema,
-
ALKIS-ATKIS-AFIS-Fachschema,
-
AAA-Versionierungsschema sowie
-
NAS-Operationen.
Das Basisschema ist die Grundlage für die Modellierung der Fachobjekte in den Fachschemata. Das Versionierungsschema zeigt das Konzept zur Historisierung von Fachobjekten auf. Ein internes Schema (Implementierungsmodell) ist nicht Bestandteil der gemeinsamen Modellierung; es entsteht durch Abbildung des konzeptuellen Anwendungsschemas in spezifische GIS-Systeme im Zuge der Implementierung. Auf Basis des Anwendungsschemas sind schließlich Operationen für den Datenaustausch und fachliche Festlegungen für Datenausgaben definiert.
Externe Anwendungsschemata (z.B. GV_Geometrische Verbesserungen) können unabhängig vom AAA-Anwendungsschema fortgeführt, bzw. versioniert werden. Daher wurden dies Anwendungsschemata auch außerhalb des AAA-Anwendungschemas modelliert. Es ist jedoch stets eine Referenz auf die Version des AAA-Anwendungsschemas anzugeben, auf die sich das jeweilige Applikationsschema bezieht (Tagged Value AAA:AAAVersion). Die Metamodelle zum Objektartenkatalog (AAA_Objektartenkatalog) und Signaturenkatalog (AAA_Signaturenkatalog) werden ebenfalls unabhängig vom AAA_Anwendungsschema modelliert und fortgeführt, da sie keinerlei Beziehung zum Basischema haben. Hier ist selbst die Referenz zum dazugehörigen AAA-Anwendungsschema nicht erfoderlich und kann unabhängig davon versioniert und fortgeführt werden.
Das Datum einer Version (Releasedatum) ist für eine eindeutige Referenz zwischen den Anwendungsschemata nicht erforderlich und in diesem Zusammenhang eine zur Versionsnummer redundante Information. Das Datum erscheint jedoch als zeitlicher Anhaltspunkt der Veröffentlichung in den Anwendungsschemata und den daraus abgeleiteten Dokumenten.
3.3. Das AFIS-ALKIS-ATKIS-Basisschema
Das AFIS-ALKIS-ATKIS-Basisschema (AAA-Basisschema) bildet die Grundlage der fachlichen Modellierung der AFIS-, ALKIS- und ATKIS-Objekte und für den Datenaustausch. Auf seiner Basis werden die Fachschemata erstellt. Seine Anwendung ist nicht auf AFIS, ALKIS und ATKIS beschränkt. Andere Fachinformationssysteme können die im Basisschema definierten Klassen zur Modellierung ihres Fachschemas ebenfalls nutzen.
Da bislang im Basisschema keine Geometrietypen zur Beschreibung von volumenförmigen Objekten enthalten waren, wurde die Ergänzung der AAA-Basisschemaklassen zur Aufstellung eines 3D-Fachschemas erforderlich.
Das Basisschema gliedert sich in die Pakete "AAA_Basisklassen", "AAA_SpatialSchema", "AAA_GemeinsameGeometrie", "AAA_UnabhaengigeGeometrie", "Codelisten", "AAA_Praesentationsobjekte", AAA_Punktmengenobjekte, AAA_Projektsteuerung, AAA_Nutzerprofile, AAA_Operationen, AAA_Praesentationsobjekte_3D, und AAA_Unabhaengige Geometrie_3D.
Die Pakete AAA_Nutzerprofile und AAA_Operationen dienen lediglich der Verankerung einer Nutzerverwaltung bzw. einer Operationsmodellierung im Basisschema. Sie enthalten nur leere, abstrakte Klassen, die von den jeweiligen Fachschemata weiter ausgefüllt werden müssen. Sie werden im Folgenden deshalb nicht weiter erläutert.
Zur eindeutigen Benennung der definierten Klassen wird von folgender Systematik ausgegangen:
-
Genormte Klassen behalten das jeweilige genormte Präfix im Klassennamen (z.B. FC für "Feature Catalogue", MD für "Metadata")
-
Klassen als AFIS-ALKIS-ATKIS-spezifische Ergänzungen am genormten Feature Catalogue erhalten das Präfix AC
-
Klassen mit grundsätzlicher Bedeutung für AFIS, ALKIS und ATKIS erhalten das Präfix AA
-
Klassen, die aus den ISO TS_*Component-Klassen ("simple topology") abgeleitet wurden, erhalten das Präfix TA; ebenso die sinngemäß gebildete Klasse für topologische Flächen mit multipler räumlich getrennter Geometrie (TA_MultiSurfaceComponent)
-
Klassen mit gemeinsam genutzter Geometrie erhalten das Präfix AG
-
Klassen der unabhängigen Geometrie erhalten das Präfix AU
-
Klassen der Präsentationsobjekte erhalten das Präfix AP
-
Klassen für die Modellierung von Punktmengenobjekten erhalten das Präfix AD
3.3.1. Objektbildungsgrundsätze
Die Regeln zur Erstellung von Anwendungsschemata werden durch die Norm 19109 "Rules for Application Schema" des ISO/TC 211 vorgegeben. In dieser Norm ist auch das allgemeine Modell zu Beschreibung und Bildung von Fachobjekten (General Feature Model) enthalten. Das gemeinsame Basisschema wird an das General Feature Model von ISO 19100 angeschlossen und dieses um die Metaklasse "AA_ObjektOhneRaumbezug" erweitert, um Objektklassen bilden zu können, für die kein Raumbezug zulässig ist.
Die Bildung eigenständiger Objekte ergibt sich aus der fachlichen Objektsicht. Objekte mit geometrischer Ausprägung können punkt-, linien-, flächen- und volumenförmige Beschreibungen führen oder vom Typ Punktmengenobjekt sein. Objekte ohne Raumbezug (z. B. Personen) tragen keine Geometrie und lassen sich nicht auf einen bestimmten Ort festlegen. Sie können aber mit anderen raumbezogenen und nicht-raumbezogenen Objekten in Beziehung stehen, z. B. mit Flurstücken, Gebäuden oder Adressen.
Zur Systematisierung und zur Unterstützung bei der Erstellung der Fachschemata werden im gemeinsamen AAA-Basisschema folgende Arten von Objektausprägungen vordefiniert:
-
Raumbezogene Elementarobjekte (AA_REO)
Raumbezogene Elementarobjekte sind zu bilden, wenn zusätzlich zu fachlichen Eigenschaften auch geometrische oder topologische Eigenschaften nachgewiesen werden sollen.
-
Nicht raumbezogene Elementarobjekte (AA_NREO)
Nicht raumbezogene Elementarobjekte sind zu bilden, wenn nur fachliche, aber keine geometrischen oder topologischen Eigenschaften nachgewiesen werden sollen.
-
Zusammengesetzte Objekte (AA_ZUSO)
Zusammengesetzte Objekte werden gebildet, um den Zusammenhang einer beliebigen Zahl und Mischung semantisch zusammengehörender raumbezogener Elementarobjekte, nicht raumbezogener Elementarobjekte oder zusammengesetzter Objekte herzustellen. Ein zusammengesetztes Objekt muss aber mindestens ein Objekt als Bestandteil besitzen.
-
Punktmengenobjekte (AA_PMO)
Für bestimmte Fachobjekttypen, die aus einer großen Anzahl geometrischer Orte mit jeweils gleichen Attributarten bestehen (z.B. Digitale Geländemodelle, Temperatur- und Luftdruckverteilungen), ist es günstiger, statt einzelner REOs ein alle Angaben klammerndes Objekt -ein sogenanntes Punktmengenobjekt- zu nutzen. Ein Punktmengenobjekt ist eine Abbildung einer Menge von Geometrien auf die zugehörigen Attributwerte.
Elementarobjekte sind die kleinste mögliche fachliche Einheit. Die Bildung von Objektteilen oder von Linien als Objektbestandteile mit fachlicher Information wie in den bisherigen Systemen ALK und ATKIS entfällt.
Die Führung der Historie von Objekten wird unterstützt. Ebenso werden Integrations- und Verknüpfungsmöglichkeiten der Fachobjekte mit den Fachdaten anderer Fachbereiche unterstützt.
Alle instanziierbaren fachlichen Objektklassen sind in den anwendungsbezogenen Subschemata aus den folgenden Objektklassen des Basisschemas durch Vererbung abzuleiten:
-
AA_ZUSO
-
AA_NREO
-
AA_PMO
-
TA_PointComponent
-
TA_CurveComponent
-
TA_SurfaceComponent
-
TA_MultiSurfaceComponent
-
AG_Objekt
-
AG_Punktobjekt
-
AG_Linienobjekt
-
AG_Flaechenobjekt
-
AU_Objekt
-
AU_Punktobjekt
-
AU_Punkthaufenobjekt
-
AU_Linienobjekt
-
AU_KontinuierlichesLinienobjekt
-
AU_Flaechenobjekt
-
AU_Punktobjekt_3D
-
AU_Umringobjekt_3D
-
AU_Punkthaufenobjekt_3D
-
AU_Mehrfachflaechenobjekt_3D
-
AU_MehrfachlinienObjekt_3D
-
AU_Geometrieobjekt_3D
-
AU_KoerperObjekt_3D
-
AU_TrianguliertesOberflaechenObjekt_3D
-
AD_PunktCoverage
-
AD_GitterCoverage
Für Präsentationsobjekte können folgende Objektklassen des Basisschemas direkt verwendet bzw. instanziiert werden:
-
AP_PPO
-
AP_PTO
-
AP_LTO
-
AP_LPO
-
AP_FPO
-
AP_Darstellung
-
AP_KPO_3D
Alternativ ist zugelassen, dass aus diesen Objektklassen des Basisschemas durch Vererbung weitere instanziierbare fachliche Objektklassen abgeleitet werden.
3.3.2. Attribute
Die in den Fachschemata zu beschreibenden Objekte können selbstbezogene Eigenschaften (Attribute) besitzen. Attribute sind die Träger der statischen Informationen der Objekte. Attribute werden immer über einen Namen und eine Werteart definiert. Wertearten können sowohl Basisdatentypen (Zahlen, Zeichenketten, Datums- und Zeitangaben) als auch komplexe Datentypen wie Geometrien oder Qualitätsmerkmale sein. Attribute können grundsätzlich multipel und Zeichenketten beliebig lang sein.
Attribute vom Typ Datums- und/oder Zeitangabe ("DateTime") werden entsprechend den Festlegungen von ISO 8601, Kapitel 5.4.1 in Verbindung mit 5.3.3 modelliert. Hierbei wird die Variante mit Trennzeichen gewählt. Zeitgenauigkeit ist die volle Sekunde, Zeitzone ist immer UTC (Universal Time Coordinated, Greenwich Mean Time, Abkürzung: Z). Beispiel: 2004-02-29T10:15:30Z
3.3.3. Beziehungen
Die in den Fachschemata zu beschreibenden Objekte können fremdbezogene Eigenschaften (Beziehungen bzw. Relationen) besitzen. In den Fachschemata können verschiedene Arten von Beziehungen verwendet werden:
-
Nach dem General Feature Model von ISO können Fachobjekte beliebige Beziehungen zueinander eingehen. Diese werden in den fachspezifischen Subschemata definiert.
-
Daneben sind im gemeinsamen Basisschema bereits einige Beziehungen zwischen Objekten fest vorgegeben:
-
Relation zur Bildung von Zusammengesetzten Objekten (ZUSO)
Ein ZUSO setzt sich aus mindestens einem Objekt zusammen. Die Klammer um diese Objekte bildet die Assoziation Zusammensetzung zwischen "AA_ZUSO" und "AA_Objekt". -
Unterführungsrelation
Unterführungsrelationen (hatDirektUnten ) werden verwendet, um eine relative vertikale Lage einzelner Objekte im Verhältnis zu anderen Objekten abzubilden. Die Angabe einer absoluten "Höhenstufe" ist durch Verwendung von Überführungs- bzw. Unterführungsrelationen nicht möglich, da derartige Relationen immer nur die Zweierbeziehung zwischen den beteiligten Objekten beinhalten. -
Kartengeometrie
Die Relation von Kartengeometrieobjekten (=generalisierte Geometrie, zu den zugehörigen Basisobjekten (istAbgeleitetAus) gibt an, aus welchen Objekten die Kartengeometrieobjekte abgeleitet sind. -
Fachdatenverbindung
Soll ein AFIS-, ALKIS- oder ATKIS-Objekt auf ein Fachdatenobjekt zeigen, das in einem fremden Fachdatensystem geführt wird, so kann dies optional durch das Attribut zeigtAufExternes beschrieben werden. Fachdatenverbindungen werden gemäß Abschnitt 3.3.8 strukturiert.Der Aufbau der Fachdatenverbindung ist sinnvoll, um bei der Benutzung und Fortführung von ALKIS die Existenz von Fachdatenbeständen zu berücksichtigen.
-
Darstellungsrelation
Präsentationsobjekte dienen der Darstellung von Objekten der Bestandsdaten. Dieser Zusammenhang wird durch den Verweis dientZurDarstellungVon zwischen dem Präsentationsobjekt und anderen Objekten nachgewiesen.
-
3.3.4. Raumbezug, Geometrie
3.3.4.1. Grundsätze
Die ISO-Norm 19107 Spatial schema stellt Raumbezugsgrundformen für die Verwendung in Anwendungsschemata zur Verfügung; für AFIS, ALKIS und ATKIS werden davon zur Verringerung der Komplexität ausschließlich folgende verwendet:
| Geometrische Objekte (GM_Object) | Topologische Objekte (TP_Object) | |||
|---|---|---|---|---|
Geometrische Primitive |
Geometrische Komplexe |
Geometrische Aggregate |
Topologische Primitive |
Topologische Komplexe |
GM_Point |
GM_CompositeCurve |
GM_MultiPoint |
TS_PointComponent |
TP_Complex |
Auch die Repräsentation der 3D-Geometrien basiert auf der ISO 19107. Die bereits im AAA-Basisschema vorhandenen Raumbezugsgrundformen werden um die in der folgenden Tabelle dargestellten erweitert:
Geometrische Objekte (GM_Object) |
||
Geometrische Primitive |
Geometrische Komplexe |
Geometrische Aggregate |
GM_Solid |
GM_CompositeSolid |
|
Die geometrischen und topologischen Objekte sind als UML-Klassen beschrieben. Die Norm enthält auch räumliche Operationen, die die geometrischen und topologischen Objekte (GM_Object bzw. TP_Object) als Parameter benutzen (Erstellen, Löschen, Ändern, räumliche Auswertungen …). Die definierten Klassen finden keine direkte Verwendung, d.h. sie sind nicht instanziierbar. Ihre Nutzung in speziellen Anwendungsschemata wird mittels Vererbung erreicht; soweit die Klassen des Spatial Schema für AFIS, ALKIS und ATKIS nicht um spezielle Eigenschaften ergänzt werden, werden sie jedoch in diesem Anwendungsbereich zur Vereinfachung unmittelbar verwendet.
Die Raumbezugsgrundformen werden in der Regel als selbstbezogene Eigenschaften (Attribute) der Objekte geführt; dies bedeutet jedoch nicht, dass der Nachweis der Geometrie grundsätzlich redundant erfolgt. Das gemeinsame AFIS-ALKIS-ATKIS-Anwendungsschema verfügt hinsichtlich der Anbindung des Raumbezuges über folgende Möglichkeiten:
-
Bildung knotenförmiger, kantenförmiger und maschenförmiger Objekte mit "einfacher Topologie". Zusätzlich maschenförmige Objekte mit "einfacher Topologie", die aus zwei oder mehr räumlich getrennt liegenden Maschen bestehen (wird zur Modellierung von Überhakenflurstücken benötigt).
Es wird das ISO-Schema "Simple Topology" verwendet, das topologische Eigenschaften durch geometrische Eigenschaften ausdrückt, aber topologische Funktionalität bietet. -
Bildung punktförmiger, linienförmiger und flächenförmiger Objekte, die sich gegenseitig Linien und Punkte teilen.
-
Bildung punktförmiger, linienförmiger, flächenförmiger und volumenförmiger Objekte mit voneinander "unabhängiger" Geometrie.
-
Bildung von topologischen und geometrischen "Themen", die es erlauben, selektiv Objektarten zu sogenannten Komplexen zusammenzufassen, um geometrische Identitäten und/oder topologische Zusammenhänge auszudrücken.
-
TriangulatedSurface (Grundlage für 3D-DGM)
-
Eine triangulierte Oberfläche ergibt sich durch die Oberflächenaufteilung in Dreiecke, durch Triangulation mittels bestimmter Algorithmen z.B. durch Delaunay-Triangulation.
-
Beispielsweise ist die Geometrie eines Tin-Reliefs durch den GML-Geometrietyp gml:TriangulatedSurface definiert. In Fachschemata kann entweder der Geometrietyp gml:TriangulatedSurface verwendet werden oder seine Unterklasse gml:tin.
Jedes raumbezogene AFIS-ALKIS-ATKIS-Fachobjekt (AA_REO) verweist auf maximal eine Geometrie. Besteht die Notwendigkeit, zu einem Realwelt-Objekt mehrere Geometrien vorzuhalten (z.B. Generalisierung, unterschiedliche Koordinatenreferenzsysteme, Punkt- und Flächengeometrie), so ist jeweils ein eigenständiges Fachobjekt (ggf. als Kartengeometrieobjekt) zu bilden.
Die erforderlichen Erweiterungen und Einschränkungen des Spatial Schema von ISO sind in den folgenden Abbildungen zusammenfassend dargestellt:
Bezüglich der Verwendung von Geometrien bei raumbezogenen Objekten werden folgende Einschränkungen in der Beschreibung der Klassen angegeben:
Der Auswahldatentyp AA_Flaechengeometrie erlaubt die alternative Modellierung flächenförmiger Objekte durch eine Fläche oder eine Menge von Flächen.
GM_MultiSurface ist nur zulässig, wenn die Anzahl der enthaltenen GM_PolyhedralSurface >=2 ist und räumlich getrennte Flächen nachgewiesen werden müssen. Räumlich nicht getrennt liegende Flächen sind immer durch 1 Fläche (GM_PolyhedralSurface) abzubilden, es sei denn, die Erfassung sehr großer Flächen erfordert eine GM_CompositeSurface.
Der Auswahldatentyp AA_Liniengeometrie erlaubt es, linienförmige Objekte wahlweise durch eine einzelne Linie oder durch mehrere aufeinander folgende Linien geometrisch zu modellieren. GM_CompositeCurve ist nur zulässig, wenn die Anzahl der enthaltenen GM_Curve >=2 ist.
Die instanziierbaren Klassen für die raumbezogenen Fachobjekte sind ausschließlich aus den folgenden, im gemeinsamen Basisschema definierten abstrakten Supertypen abzuleiten:
Objekte mit einfacher Topologie
-
TA_PointComponent,
-
TA_CurveComponent
-
TA_SurfaceComponent,
-
TA_MultiSurfaceComponent
Objekte mit gemeinsamer Punkt- und/oder Liniengeometrie
-
AG_Objekt
-
AG_Punktobjekt
-
AG_Linienobjekt
-
AG_Flaechenobjekt
Objekte mit unabhängiger Geometrie
-
AU_Objekt,
-
AU_Punktobjekt
-
AU_PunkthaufenObjekt
-
AU_Linienobjekt
-
AU_KontinuierlichesLinienobjekt
-
AU_Flaechenobjekt
-
AU_TrianguliertesOberflaechenObjekt_3D
-
AU_MehrfachLinienObjekt_3D
-
AU_MehrfachFlaechenObjekt_3D
-
AU_UmringObjekt_3D
-
AU_Punktobjekt3D
-
AU_PunkthaufenObjekt_3D
-
AU_KoerperObjekt_3D
-
AU_GeometrieObjekt_3D
Für Präsentationsobjekte sind folgende Typen zu verwenden. Diese Klassen können auch direkt instanziiert werden:
-
AP_PPO
-
AP_PTO
-
AP_KPO_3D
-
AP_LTO
-
AP_LPO
-
AP_FPO
Als Geometrie für Linien bzw. Flächenumringe sind lediglich folgende Arten von Curve-Segmenten (Interpolationsarten) zulässig:
-
GM_LineSegment
-
GM_LineString
-
GM_Arc
-
GM_Circle
-
GM_CubicSpline.
Bei GM_Arc muss der 2. ControlPoint im mittleren Drittel des Kreisbogens liegen; falls möglich, soll der Scheitelpunkt des Kreisbogens genommen werden. Bei GM_Circle dürfen die jeweiligen Abstände der ControlPoints (1=4,2,3) nicht weniger als ein Sechstel des Kreisumfangs betragen.
3.3.4.2. Objekte mit einfacher Topologie
ISO 19107 Spatial schema bietet als Modul für ein Anwendungsschema unmittelbar das Schema Simple topology an. Auf dieser Basis werden Objekte bereitgestellt, die topologische Eigenschaften durch geometrische Eigenschaften ausdrücken. Als Anwendung dieses Moduls stellt das Basisschema die Klassen TA_*Component zur Verfügung. Diese Klassen bieten zusätzlich zu den entsprechenden Klassen des Spatial Schema die allgemeinen Eigenschaften aller AFIS-ALKIS-ATKIS-Objekte (Identifikator, Lebenszeitintervall, Anlass) sowie die Möglichkeit, verschiedene Objektarten über das Konstrukt des "PunktLinienThemas" topologisch und geometrisch zu verknüpfen. Die TA-Klassen können gleichzeitig einem topologischen Thema und einem oder mehreren PunktLinienThemen angehören. Die Klasse TA_MultiSurfaceComponent wurde abweichend zur Klasse TA_SurfaceComponent definiert, um zu erreichen, dass die referenzierten Maschen (TS_Face) auch Realisierungen getrennt liegender Flächen (GM_OrientableSurface) sein können. Damit ist auch die topologische Modellierung von Exklaven möglich. Exklaven sollen deshalb nicht über Relationen von Fachobjekt zu Fachobjekt (Relation Composite [composite > component] zwischen TS_Feature und TS_Feature) modelliert werden.
3.3.4.3. Objekte mit gemeinsam genutzter Geometrie
Das Paket "AAA_GemeinsameGeometrie" stellt Basisklassen für Fachobjekte (Features) zur Verfügung, deren Geometrie aus Punkten, Linien und Flächen bestehen, die sich jeweils ihre Geometrie teilen.
Dazu werden die Eigenschaften des erweiterten "AAA-SpatialSchema" genutzt, das zusätzlich das Konstrukt des "PunktLinienThemas" zur Verfügung stellt. Außerdem wird die Geometrie durch die gemäß ISO 19107 und 19109 für die gemeinsame Nutzung von Geometrie vorgesehenen Raumbezugsgrundformen (GM_PointRef und GM_CompositeCurve) ausgedrückt. Damit sind die geometrietragenden Primitive (GM_Point und GM_Curve) relational mit den Fachobjekten verbunden und können so von mehreren Fachobjekten gemeinsam genutzt werden. Die gemeinsame Nutzung von Geometrie bezieht sich nur auf Punkte und Linien, nicht auf Flächengeometrien. Linien werden vereinigt und einer gemeinsamen Nutzung zugeführt, wenn sie exakt in allen Stützpunkten gleich sind und gleiche Linieninterpolationen aufweisen; Linien, die sich kreuzen, zerschlagen sich nicht. Die Basisklassen "AG_Objekt", "AG_Punktobjekt", "AG_Linienobjekt" und "AG_Flaechenobjekt" sollen für die Definition von raumbezogenen Objektarten mit gemeinsamer Geometrie verwendet werden.
3.3.4.4. Objekte mit unabhängiger Geometrie
Zwei Pakete beschreiben Objekte mit unabhängiger Geometrie:
-
Das Paket "AAA_UnabhaengigeGeometrie" stellt sechs Basisklassen für Fachobjekte zur Verfügung, deren Geometrie aus voneinander unabhängigen Punkten, Linien und Flächen bestehen.
-
Das Paket AAA_Unabhängige Geometrie 3D stellt Basisklassen für 3D-Fachobjekte (Features) zur Verfügung, deren Geometrien voneinander unabhängig sind.
Diese Basisklassen sollen als Basis raumbezogener Objektarten mit unabhängiger Geometrie verwendet werden (z.B. Präsentationsobjekte).
AU_Flaechenobjekt wird für Fachobjekte verwendet, die geometrisch durch Flächen beschrieben werden.
Ein AU_Linienobjekt wird geometrisch durch einen Set von Linien beschrieben (Anwendungsfall: z.B. Felssignatur).
AU_Punktobjekt beinhaltet ein Fachobjekt, das geometrisch durch einen einzelnen Punkt repräsentiert wird.
Der Auswahldatentyp "AU_Objekt" erlaubt es, Subklassen zu bilden, bei denen die konkrete Art des Geometrietyps erst auf Instanzenebene festgelegt wird. Zur Auswahl stehen verschiedendimensionale Geometrien: Punkt, Linie, Fläche und zusammengesetzte Linie. Damit ist es z.B. möglich, eine Objektart "Turm" zu bilden, die in Abhängigkeit von der Ausdehnung in der Realwelt punktförmige oder flächenförmige Geometrie hat.
Fachobjekte, die geometrisch durch zusammenhängende Linien beschrieben werden, erben von "AU_KontinuierlichesLinienobjekt". Die Geometrie eines solchen Objekts darf sich nicht kreuzen und nicht überlagern. Anwendungsfall: z.B. Leitung.
"AU_Punkthaufenobjekt" wird für ein Objekt verwendet, das geometrisch durch einen Punkt oder einen Punkthaufen repräsentiert wird. Ein Auswahldatentyp "AA_Punktgeometrie" erlaubt es, punktförmige Objekte alternativ mit einer oder mehreren Punktgeometrien zu bilden. Die Anwendung ist nur bei Objekten mit unabhängiger Geometrie sinnvoll. (z.B. Präsentationsobjekte mit Signaturhaufen mit individueller Geometrie).
Bei 3D-Objekten mit unabhängiger Geometrie sind Verschneidungen möglich. Die Modellierung ist erheblich einfacher, da keine Einschränkungen bei der gemeinsamen Nutzung unterschiedlicher Raumbezugsgrundformen bestehen. Für Visualisierungszwecke ist diese Art der Geometrie ausreichend.
Bei dem Nachweis von 3D-Geobasisdaten (Block-/ Klötzchenmodell) wird jedoch die redundanzfreie Geometrie empfohlen, bzw. sollte auf die Verschneidung von Geometrien verzichtet werden.
Das Paket "AAA_Unabhaengige Geometrie 3D" stellt Basisklassen für 3D Fachobjekte (Features) zur Verfügung, deren Geometrie aus voneinander unabhängigen 3D Punkten, 3D Linien, 3D Flächen und 3D Körpern besteht. Diese Basisklassen sollen als Basis raumbezogener Objektarten für 3D Fachanwendungen mit unabhängiger Geometrie verwendet werden (z.B. Präsentationsobjekte).
"AU_ObjektMitUnabhaengigerGeometrie_3D" ist die Oberklasse zu den acht Klassen mit unabhängiger 3D Geometrie. Ein "AU_ObjektMitUnabhaengigerGeometrie_3D" ist ein Raumbezogenes Elementarobjekt für 3D Fachanwendungen (AA_REO_3D), dessen Subklassen sich auf der Ebene der Instanzen keine Geometrie teilen. Die Klasse ist nicht direkt instanziierbar.
-
AU_Punktobjekt_3D ist ein 3D Fachobjekt, das geometrisch durch einen einzelnen 3D Punkt repräsentiert wird.
-
AU_PunkthaufenObjekt_3D ist ein 3D Fachobjekt, das geometrisch durch einen 3D Punkthaufen repräsentiert wird.
-
AU_MehrfachLinienObjekt_3D ist ein 3D Fachobjekt, das geometrisch durch 3D Linien beschrieben wird. Es sind mehrere getrennt liegende 3D Linien zulässig.
-
AU_MehrfachFlaechenObjekt_3D ist ein 3D Fachobjekt, das geometrisch durch 3D Flächen beschrieben wird. Es sind mehrere getrennt liegende 3D Flächen zulässig.
-
AU_TrianguliertesOberflaechenObjekt_3D ist ein 3D Fachobjekt, das geometrisch durch räumlich zusammenhängende 3D Flächen beschrieben wird, die eine triangulierte Oberfläche (TIN) definieren (z.B. eine Geländeoberfläche).
-
AU_KoerperObjekt_3D ist ein 3D Fachobjekt, das geometrisch durch 3D Körper beschrieben wird.
-
AU_UmringObjekt_3D ist ein 3D Fachobjekt, das geometrisch durch ein 3D Umringspolygon beschrieben wird, und weitere 3D Umringspolygone für Enklaven aufweisen kann. Jeder Teil der Geometrie muss ein geschlossener Umring sein.
-
AU_GeometrieObjekt_3D ist ein 3D Fachobjekt, das es erlaubt, Subklassen zu bilden, bei denen die konkrete Art des 3D Geometrietyps erst auf Instanzenebene z.B. in Abhängigkeit von der Detaillierungsstufe (Level of Detail) festgelegt wird (z.B. Mauern die durch 3D Flächen oder detaillierter durch 3D Körper repräsentiert werden können).
3.3.4.5. Raumbezugssystem, Koordinaten
In AFIS-ALKIS-ATKIS kann für jede Geometrie das zugehörige Koordinatenreferenzsystem (CRS) angegeben bzw. gespeichert werden.
Nach der Norm ISO 19111 (Spatial Referencing by Coordinates) besteht ein Koordinatenreferenzsystem aus zwei Komponenten, dem "Datum" und dem "Koordinatensystem" (siehe folgende Skizze).
Das Datum ist der physikalische Teil eines CRS, das per Definition des Nullpunkts, der Orientierung der Koordinatenachsen und des Maßstabs den Bezug zur Erde festlegt. Ein Datum kann ein geodätisches Datum, ein vertikales Datum oder ein ingenieurtechnisches bzw. lokales Datum sein. Beispiele für ein geodätisches Datum sind das Deutsche Hauptdreiecksnetz (DHDN), auch "Potsdam-Datum" genannt, oder das Europäische Terrestrische Referenzsystem 1989 (ETRS89).
Das Koordinatensystem ist der mathematische Teil eines CRS, der durch Regeln festlegt, wie einer Geometrie, z. B. einem Festpunkt, Koordinaten zugewiesen werden. Die Koordinaten einer Geometrie können z. B. als kartesische Koordinaten (X, Y, Z), ellipsoidische Koordinaten (Breite, Länge und ggf. ellipsoidische Höhe) oder projizierte Koordinaten (Gauß-Krüger-Abbildung, UTM-Abbildung) angegeben werden.
Neben den CRS für 2-D-Lageangaben und 3-D-Positionsangaben sind für die Führung von Höhenangaben bzw. -koordinaten (z.B. NN-Höhen) eigene Koordinatenreferenzsysteme definiert. Die in Deutschland gebräuchlichen Koordinatenreferenzsysteme für Lage, Position und Höhe sind in Abschnitt 8.1, “Koordinatenreferenzsysteme für AFIS-ALKIS-ATKIS” mit ihren Bezeichnungen und Kurznamen aufgelistet.
Die Art des Koordinatenreferenzsystems bestimmt die Anzahl der vorhandenen Koordinatenwerte (z.B. Rechtswert, Hochwert oder Rechtswert, Hochwert, Höhe). Grundsätzlich können nach ISO 19111 auch zusammengesetzte CRS eingeführt werden. Bei Objekten der Objektart "Punktort" sind in AFIS-ALKIS-ATKIS gemäß der Definition der Objektart Punktort zusammengesetzte Koordinatenreferenzsysteme jedoch nicht zugelassen.
3.3.5. Signaturierung, Präsentationsobjekte
Die Präsentationsobjekte sind wegen den allgemeingültigen Eigenschaften im AAA Basisschema beschrieben.
Die Präsentationsobjekte enthalten eine Signaturnummer und weitere Eigenschaften zur Steuerung der Präsentation, wie z. B. Darstellungspriorität und Art. Präsentationsobjekte müssen in ALKIS mit den entsprechenden Fachobjekten durch eine Relation "dientZurDarstellungVon" verbunden sein. In ATKIS gibt es keine derartige Regel, d.h. es dürfen "freie Präsentationsobjekte" existieren. Die Präsentation von Objekten in graphischen sowie nicht graphischen Ausgaben erfolgt gemäß nachstehender Abbildung in folgender Weise:
Präsentation in der Karte
-
Präsentationsobjekte im Bestand
Präsentationsobjekte werden für alle Signaturen in Form von Schrift, Symbol, Linie, Fläche angelegt, die nicht vollautomatisch für einen bestimmten Zielmaßstab erzeugt und platziert werden können. Die konkrete Signaturnummer, die eine Ableitungsregel repräsentiert, sowie die Positionierungsnummer, die für eine bestimmte Positionierungsregel steht, kann optional im Präsentationsobjekt gespeichert werden. Präsentationsobjekte sind auch dann zu bilden, wenn bei der Ausgabe von der im Signaturenkatalog festgelegten Standarddarstellung abgewichen werden soll (z.B. abweichende Schrifthöhe der Flurstücksnummer). -
Präsentation mittels Ableitungs- und Positionierungsregel
Signaturen eines Fachobjektes in Form von Schrift, Symbol, Linie, Fläche werden an einer definierten Stelle (Standardposition) unter Anwendung des Filter Encodings und einer konkreten Ableitungsregel, die zu einer bestimmten Signaturnummer führt und den Positionierungsregeln, die eine bestimmte Positionierungsnummer aktiviert, platziert. In diesem Falle wird ein Präsentationsobjekt in den Bestandsdaten nicht angelegt. Die darzustellende fachliche Information wird aus der angegebenen Attributart der Fachobjektart ermittelt. Dieser Weg wird als die Standardvariante betrachtet, der aber durchaus aus Gründen der Performance nicht immer effizient ist. -
Präsentation mittels gespeicherter Ableitungs- und Positionierungsregel
Um die Performance der Präsentation für die Standardvariante zu erhöhen, wird zu einem bestimmten Zeitpunkt (Ersteinrichtung, Fortführung) die konkrete Signaturnummer sowie die Positionierungsnummer mit der ein Fachobjekt zur Darstellung gebracht werden soll, unter dem zugeordneten Präsentationsobjekt AP-Darstellung als NREO gespeichert. Der Vorteil gegenüber der Bildung von Präsentationsobjekten (Variante 1) ist die Vermeidung von Redundanzen der Geometrie, da bei AP-Darstellung die Darstellungsgeometrie aus dem jeweiligen Fachobjekt abgeleitet wird. Zum Zeitpunkt der Präsentation wird durch Anwendung des Filter Encodings in Verbindung mit der Ableitung der Darstellungsgeometrie aus dem Fachobjekt und den gespeicherten Regeln, sprich Signaturnummer, Positionierungsnummer, die Darstellung schnellstmöglich herbeigeführt. Die Objektart AP_Darstellung wird in ALKIS dazu verwendet, um folgende Veränderungen in einer Liegenschaftskarte herbeizuführen:-
Unterdrückung einer Darstellung in der Liegenschaftskarte,
-
Herbeiführung einer bestimmten Bemusterung in der Liegenschaftskarte, wie z. B. flächenhafte Bemusterung.
-
Präsentation der Liegenschaftsbeschreibung
Die Präsentation der Angaben für eine Liegenschaftsbeschreibung, wie z. B. Flurstücks- und Eigentümernachweis, erfolgt ausschließlich zur Laufzeit über die Anwendung des Filter Encodings und der Regeln, die im AAA-Ausgabekatalog hinterlegt sind. Diese Ausgabedaten werden in Verbindung mit einer konkreten Ableitungsregel aus dem nicht formalisierten Signaturenkatalog präsentiert. Die jeweiligen Textpositionen können dem entsprechenden Standbogen entnommen werden. Muster für die Produktausgabe sind ein zusätzlicher Anhalt.
Erzeugung der Präsentationsobjekte und AP_Darstellung für den Bestand
Um eine effiziente Präsentation der Fachobjekte in einer Ausgabe zu gewährleisten, müssen bereits zum Zeitpunkt der Erhebung / Fortführung geeignete Präsentationsvorgaben festgelegt werden. Es werden dabei, gemäß Abbildung 19 drei Fälle unterschieden:
-
Keine Festlegung von Präsentationsvorgaben
Die in der Erhebung / Fortführung erzeugten ALKIS- strukturierten Erhebungsdaten brauchen für eine schnelle Präsentation in einer Ausgabe keine vordefinierten Festlegungen in Form der Zuweisung einer konkreten Signatur- bzw. Positionierungsnummer. Die für eine Präsentation benötigten Angaben können direkt während der Laufzeit für eine Darstellung aus dem 3A- Datenmodell generiert werden. -
Speicherung von Präsentationsobjekten im Bestand
In der Erhebung / Fortführung wird zur Darstellung von konkreten Signaturen eines Fachobjektes ein Präsentationsobjekt angelegt, da die Signaturen z. B. nicht vollautomatisch für einen bestimmten Zielmaßstab erzeugt und platziert werden können. Hierbei werden die Angaben über die Geometrie, optional eine Signaturnummer und / oder optional eine Positionierungsnummer im Objekt gespeichert. -
Festlegung von Präsentationsvorgaben
Zur Minimierung der Laufzeit einer Präsentation kann in der Erhebung / Fortführung für ein Fachobjekt die Objektart AP_Darstellung als NREO angelegt werden, in der eine konkrete Positionierungsnummer gespeichert wird, so z. B. die Bemusterung einer Fläche. Die Geometrie für die Präsentation wird zur Laufzeit aus dem Fachobjekt mit geeigneten Methoden abgeleitet.
Präsentationsobjekte 3D
Das Paket AAA_Praesentationsobjekte_3D konkretisiert die Fachobjekte von AAA_Unabhaengige Geometrie 3D für die Zwecke der Präsentation. Die entsprechenden Fachobjekte können unmittelbar instanziiert werden.
Das 3D Präsentationsobjekt AP_KPO_3D wird für 3D Symbole verwendet, deren 3D Geometrie in einem externen Datenformat gespeichert wird und über eine URI referenziert wird. AP_KPO_3D leitet sich aus AU_Punktobjekt_3D ab und seine 3D Punktgeometrie positioniert das Symbol. Über eine Transformationsmatrix wird die lageunabhängige 3D Geometrie in dem externen Datenformat in den Raumbezug des Präsentationsobjektes AP_KPO_3D transformiert. Die Präsentationsobjekte sind wie andere Objekte im Objektartenkatalog in Verbindung mit dem jeweiligen Signaturenkatalog bzw. 3D Symbolbibliotheken zu definieren.
Regelung von länderübergreifend redundanzfreier Vergabe länderspezifischer Signaturnummern
Das AFIS-ALKIS-ATKIS-Datenmodell bringt den Anwendern neben vielen anderen Vorteilen eine länderübergreifende Vereinheitlichung der Datenbestände sowie deren Präsentation.
Der Bedarf an frei gestaltbaren Ausgaben seitens der Länder besteht. Dies belegen mehrere landespezifische Signaturenkataloge. Bei deren Schaffung wurden unterschiedliche Wege beschritten, exemplarisch hier anhand zweier Bundesländer aufgezeigt:
Baden-Württemberg hat als einziges Bundesland im ALKIS-Signaturenkatalog der AdV länderspezifische Anteile mit eigenen Signaturnummern unterbringen können. Eine Erweiterung um länderspezifische Anteile weiterer Länder ist von der AdV nicht beabsichtigt, da sie für die Pflege länderspezifischer Vorgaben nicht zuständig ist.
Nordrhein-Westfalen hat einen eigenen ALKIS-Signaturenkatalog geschaffen, dessen Inhalte unabhängig neben dem der AdV veröffentlicht werden.
Folgende Regelung gewährleistet die Redundanzfreiheit der Signaturnummern bei länderspezifischen Erweiterungen des ALKIS-Signaturenkataloges. Damit wird vermieden, dass länderübergreifende Datennutzer zukünftig möglicherweise mit identischen Signaturnummern verschiedener Länder konfrontiert werden, die inhaltlich unterschiedliche Präsentationen bewirken sollen. Es gelten folgende Vorgaben:
-
Bei allen länderspezifischen Präsentationsobjekten ist das Attribut 'signaturnummer' Pflichtattribut.
-
Mit länderspezifischen Signaturnummern einhergehende Präsentationsregeln sind länderspezifisch auszuprägen.
-
Länderspezifische Signaturnummern bestehen aus dem Länderkürzel (bzw. "BU" oder "BKG") gemäß Abschnitt 3.3.9, “Identifikatoren, Verknüpfungen”, unmittelbar gefolgt von der vierstelligen Ziffernfolge der Signaturnummer. Sie werden in dem Attribut AP_GPO.signaturnummer (bzw. entsprechenden Erben) geführt. Beispiele: RP4141, NW0311.
3.3.6. Kartengeometrieobjekte
Als Kartengeometrieobjekte werden diejenigen Fachobjekte definiert, die bei der Ableitung für einen bestimmten Kartenmaßstab aus Gründen der kartographischen Generalisierung ihre geometrische Form und / oder Lage verändert haben. Ein Kartengeometrieobjekt muss folgende eigenständige Informationen enthalten: Den Identifikator, die Angabe des Kartenmodells, z. B. DTK10, zu dem es gehört, die einseitige Relation ist_abgeleitet_aus auf das zugrundeliegende AFIS-ALKIS-ATKIS-Objekt sowie die eigentliche Geometrie. Darüber hinaus muss es die Attribute des zugrundeliegenden AFIS-ALKIS-ATKIS-Objekts enthalten, um in den Ableitungsregeln des Signaturenkatalogs für die Präsentation ausgewertet werden zu können.
3.3.7. Punktmengenobjekte
Als Punktmengenobjekte (PMO) werden Fachobjekte dann definiert, wenn einer großen Anzahl geometrischer Orte Attributwerte jeweils gleicher Attributarten zugeordnet werden soll. Dies ist im AAA-Anwendungskontext insbesondere bei Digitalen Geländemodellen, die i.d.R. Höheninformationen in einer Gitterstruktur vorhalten, der Fall. Da aber auch häufig unregelmäßig verteilte, gleichartige Informationen vorgehalten werden sollen, z.B. Höhenmesspunkte, wurde außer der Gittervariante der PMO (AD_GitterCoverage) auch eine Variante für eine beliebige Punktverteilung zugelassen (AD_PunktCoverage). Die Modellierung realisiert die Klassen aus ISO 19123 Coverages. Sie wird in der Weise eingeschränkt, dass für die Sequenz der Attributwerte (CV_SequenceType) nur "linear" zulässig ist.
3.3.8. Regelung von länderübergreifend redundanzfreier Vergabe länderspezifischer Fachdatenverbindungen
In allen AAA-Objekten kann im Attribut 'zeigtAufExternes' eine Fachdatenverbindung untergebracht werden. Die Modellierung lässt dies auf zwei Arten zu, nämlich in Form der URN- oder der URL-Variante. Im Modell steht hierzu beim Attribut AA_Fachdatenverbindung.art folgendes:
Diese Attributart definiert den Namensraum zur Spezifikation der Art der Fachdatenverbindung.
Es sind URN zu verwenden, wenn es sich um einen nicht allgemein auflösbaren Namensraum handelt. Wenn URLs verwendet werden, muss die verwiesene Ressource eine Beschreibung dieser Fachdatenanbindung zurückliefern. URLs müssen das HTTP-Protokoll verwenden.
Fachdatenverbindungen, die sich der URL-Variante bedienen, sind aufgrund der Eindeutigkeit der URNs unproblematisch.
Folgende Regelung gewährleistet die Redundanzfreiheit der Fachdatenverbindungen bei länderspezifischen Erweiterungen mit der URN-Variante. Dadurch wird vermieden, dass länderübergreifende Datennutzer zukünftig möglicherweise mit identischen Nummern von Fachdatenverbindungen verschiedener Länder konfrontiert werden, denen inhaltlich unterschiedliche Sachverhalte in Hintergrund stehen.
In Anlehnung an die in der GeoInfoDok übliche URN-Logik:
-
urn:adv:uom für Maßeinheiten,
-
urn:adv:crs für Koordinatenreferenzsysteme,
-
urn:adv:oid für Objektidentifikatoren
ist für Fachdatenverbindungen folgende URN zu verwenden:
-
urn:<Länderkürzel>:fdv:<vierstelliger Zifferncode>
wobei <Länderkürzel> gemäß Abschnitt 3.3.9, “Identifikatoren, Verknüpfungen” - jedoch in Kleinbuchstaben - ausgeprägt sein sollen und <vierstelliger Zifferncode> sich stets vierstellig aus den Ziffern 0-9 (ggf. mit führenden Nullen) zusammensetzt.
Beispiele: urn:rp:fdv:4711 bzw. urn:by:fdv:0203.
Somit wird auch in der URN-Variante der Fachdatenverbindungen die Eindeutigkeit sichergestellt. Die Zifferncodes sowie die ihnen zugeordneten Inhalte sind in jeweiliger Länderzuständigkeit auszuprägen.
-
urn:adv:fdv:<vierstelliger Zifferncode>
wobei der vierstellige Zifferncode von der AdV festgelegt und in geeigneter Weise veröffentlicht wird (z.B. AdV-online).
3.3.9. Identifikatoren, Verknüpfungen
Identifikatoren stehen stellvertretend für das Objekt, das sie repräsentieren. Daher bezeichnet man sie auch als Objektidentifikatoren oder kurz OID. Die wesentlichen Eigenschaften eines Identifikators sind:
-
Er ist systemweit eineindeutig, wobei durch die entsprechende Definition von "systemweit" die Forderung nach bundesweiter und fachübergreifender Eindeutigkeit erfüllt werden kann.
-
Sein Entstehen zeigt an, dass ein Objekt entstanden ist.
-
Er bleibt während der Lebensdauer eines Objekts unverändert. Das gilt auch bei der Migration von Daten in eine neue Version der GeoInfoDok, mit Ausnahme der untergegangenen Elemente, welche lediglich aus Gründen der Abwärtskompatibilität noch im Modell belassen wurden, siehe entsprechendes Kapitel in den Release Notes TBD: Worauf genau in den Release Notes soll verwiesen werden?.
-
Sein Untergehen zeigt an, dass ein Objekt nicht mehr existiert.
Damit ist der Lebenszyklus von Identifikatoren identisch mit dem Lebenszyklus der Objekte, deren Repräsentanten sie sind. Die Frage, wann Identifikatoren geändert werden dürfen und wann nicht, darf somit nicht aus dv-technischer Sicht beantwortet werden, sondern es müssen fachliche Kriterien benannt werden,
-
wann ein Objekt entsteht,
-
welche Änderungen es ohne Identitätsverlust verkraftet und
-
wann es untergeht.
So werden auch Objektidentifikatoren von Objekten, die von anderen Fachstellen im Rahmen ihrer Aufgaben erzeugt wurden, bei der Übernahme in die AAA-Datenhaltung unverändert übernommen. Auch bei Migration von Bestandsdaten in eine neue Version der GeoInfoDok beibt das ursprüngliche Lebenszeitintervall unverändert erhalten, mit Ausnahme der untergegangenen Elemente, welche lediglich aus Gründen der Abwärtskompatibilität noch im Modell belassen wurden, siehe entsprechendes Kapitel in den Release Notes TBD: Worauf genau in den Release Notes soll verwiesen werden?.
Für alle Fachobjekte wird eine eindeutige Bezeichnung als Objektidentifikator verwendet. Der Identifikator hat folgenden Aufbau:
| Anteile | Bedeutung | Festlegung | |
|---|---|---|---|
1 |
Weltweit eindeutige Kennung (2 Zeichen) |
Nationalität |
"DE" für Deutschland |
2 |
Präfix (6 Zeichen) |
Kennung für die den Identifikator erzeugende Implementierung oder Datenbank sowie für vorläufige Identifikatoren. |
Die Zeichen beginnen linksbündig mit den in der Norm ISO 3166-2 "Country Subdivision Code" (ISO, 15. Dezember 1998) genormten Abkürzungen der Bundesländer. Für Bundesdienststellen ist die Abkürzung "BU" vorgesehen bzw. im Falle des Bundesamtes für Kartographie und Geodäsie "BKG"; die weiteren Stellen werden durch das jeweilige Bundesland bzw. die Bundesdienststelle oder das BKG festgelegt. Soweit im Verarbeitungsprozess über die Verwendung von vollständigen Identifikatoren hinaus vorläufige Identifikatoren benötigt werden, beginnen diese linksbündig mit "_". Damit ergibt sich folgende Tabelle: Baden-Württemberg: "BW" Zulässige Zeichen sind: |
3 |
Suffix (8 Zeichen) |
Laufende Nummer |
Zulässige Zeichen sind: |
Beispiele für Identifikatoren sind:
"DENW123412345678" (endgültiger Identifikator)
"DE_0000000000001" (vorläufiger Identifikator)
Zur Realisierung einer Geodateninfrastruktur im Sinne und unter Nutzung der Schnittstellendefinitionen des Open Geospatial Consortiums (OGC) müssen alle beteiligten Stellen eine Systematik für die Vergabe der Identifikatoren und ein Service-Interface definieren, sodass sichergestellt ist, dass Objekte über ihren Identifikator ohne weiteres Wissen gefunden werden können. Hier bietet sich im Sinne einer bundesweiten Lösung ein gemeinsamer Service und auch die Publikation von AAA-Bestandsdaten als Linked Open Data an; die Systematik der Vergabe und Verteilung kann unberührt davon länderspezifisch festgelegt werden.
Um Relationen zwischen den Fachobjekten im Datenaustausch aufzubauen, werden Identifikatoren auch als Referenzen auf Fachobjekte geführt.
Identifikatoren sind unter anderem auch erforderlich, um bei der Formulierung von Fortführungen angeben zu können, welche Objekte gelöscht und welche Objekte überschrieben werden sollen. Da die Objekte dabei in ihrer konkret vorliegenden Version angesprochen werden müssen, wird der o.a. Identifikator in diesen Fällen um die Angabe von Entstehungsdatum/-zeit der angesprochenen Objektversion ergänzt.
Eine wichtige Voraussetzung für die gemeinsame Führung von Datenbeständen unterschiedlicher Herkunft ist, dass die Integrationssituation in Form von Referenzen zwischen den Daten der Vermessungsverwaltung und den Fachdaten abgebildet ist (Verknüpfung). Diese Verknüpfung kann einseitig in den raumbezogenen Basisinformationssystemen der Vermessungsverwaltung oder im Fachinformationssystem (einseitige Verknüpfung) oder gegenseitig in beiden Informationssystemen (gegenseitige Verknüpfung) erfolgen. Als Verknüpfungsmerkmale sind eindeutige Bezeichnungen zu definieren und zu führen. Diese können aus den o.a. Identifikatoren und / oder aus Fachkennzeichen der jeweiligen Datenbestände bestehen.
3.3.10. Modellart
Das AA_Objekt besitzt das Attribut modellart, welches eine Zuordnung zu einer oder mehreren Modellarten darstellt. Die erweiterbare Codelist "AA_WeitereModellart" erlaubt die Erfassung beliebiger, z.B. länderspezifischer Modellarten. Die Eintragung und Pflege solcher Wertearten und Bezeichner wird im Rahmen der AdV-Registry für Codelisten geregelt.
Die Enumeration AA_AdvStandardModell ist hingegen nicht erweiterbar und enthält die zulässigen Modellarten für die Anwendungsschemata der AdV. Durch die Angabe der Modellarten ist es möglich, sämtliche Elemente des Datenmodells (z.B. Objektarten, Attributarten etc.) einem oder mehreren Modellen zuzuordnen. Somit können trotz der einheitlichen und integrierten Modellierung unterschiedliche Fachsichten auf die Objekte der realen Welt abgebildet und in Form von fachspezifischen Objektartenkatalogen ausgegeben werden. Auswirkungen auf die NAS hat die Modellart jedoch nicht: Die NAS wird inhaltlich definiert durch das gesamte AAA-Anwendungsschema, wodurch auf der Ebene der Schnittstelle keine unterschiedlichen Fachsichten abgebildet werden können. Das bedeutet, es gibt nicht eine ATKIS- oder ALKIS-NAS, sondern nur die NAS.
Wird bei Objekt-, Attribut-, oder Wertearten keine Modellart angegeben, gibt es keine Einschränkungen bei der Verwendung von Modellarten, d.h. diese Elemente können für beliebige Modellarten verwendet werden. Umgekehrt bedeutet dies, dass bei der Angabe von Modellarten alle nicht erwähnten Modellarten asugeschlossen werden.
3.3.11. LoD-Definition
Der Level of Detail beschreibt die Detaillierungsstufe der 3D Geometrie eines raumbezogenen Elementarobjekts. Diese wird meistens durch die Erfassungs- bzw. Ableitungsmethode für die 3D Geometrie bestimmt. Es sollen nur die Level of Detail 1 bis 3 für ALKIS 3D verwendet werden. Die inverse Relationsrolle "detailliert" verweist auf das zugehörige raumbezogene Elementarobjekt mit einer 3D Geometrie in einer geringeren Detaillierungsstufe. Die Relationsrolle "generalisiert" verweist auf das zugehörige raumbezogene Elementarobjekt mit einer 3D Geometrie in einer höheren Detaillierungsstufe.
Die 3D-Ergänzung unterstützt verschiedene Levels of Detail (LoD). LoDs werden benötigt, um Gebäude und andere 3D-Objekte einem bestimmten Detailierungsgrad zuzuordnen. Ebenso dienen sie der effizienten Visualisierung und Datenanalyse.
Zur Definition der einzelnen LoD wurden folgende Dokumente herangezogen:
-
07-062_Candidate_OpenGIS_CityGML_Implementation_Specification.pdf
-
3D_Stadtmodelle, Eine Orientierungshilfe der AG Stadtmodelle des AK Kommunales Vermessungs- und Liegenschaftswesens des Städtetages NRW
Der unterste Level LoD1 ist das Blockmodell, dort werden die Gebäude als einfacher Block mit Flachdach dargestellt. Der LoD2 stellt die unterschiedlichen Dachtypen dar, die Darstellung von Vegetation ist möglich. LoD3 ist der Level mit dem höchsten Detailierungsgrad. Dort werden detaillierte Wand- und Dachstrukturen, Vegetation und Straßenmöblierung abgebildet. Neben den visuellen Kriterien liegen den LoDs geometrische Mindestanforderungen zugrunde (siehe Tabelle 1):
-
die absolute Lage- und Höhengenauigkeit sowie
-
die Grundfläche der darzustellenden Objekte.
| LoD1 | LoD2 | LoD3 | |
|---|---|---|---|
Absolute Lage-/ Höhengenauigkeit (besser als…) |
5/5m |
2/1m |
0.5/0.5m |
Darstellung |
Objektblöcke als generalisierte Form; >6*6m/3m |
Objekte als generalisierte Form; >4*4m/2m |
Objekte als reale Form; >2*2m/1m |
Dachform |
Flachdach |
Dachtyp und -ausrichtung |
Reale Form |
Fremdobjekte (Straßenmöbel) |
Wichtige Objekte |
Prototypen |
Reale Form |
In der Praxis wird es, in naher Zukunft, kein komplett texturiertes LoD geben. Aus diesem Grund bilden Texturierungen kein Kriterium für eine Einstufung in ein bestimmtes LoD und sind in allen LoD zugelassen.
3.3.12. Nutzung von Geometriebibliotheken
Die Nutzung von Geometriebibliotheken ist eine Erweiterung der Möglichkeiten der Geometrieabbildung im 3D-Bereich. Geometriebibliotheken können zur Einbindung von Prototypen verwendet werden. Beispiele hierfür sind im 3D-Bereich Bäume, Ampeln, Laternen usw. Jede prototypische Geometrie existiert nur einmal in einem lokalen, kartesischen Koordinatensystem. Diese kann im Datenbestand mehrfach, mittels URI eines speziellen Präsentationsobjektes, referenziert werden. Die prototypische Geometrie kann ein lokaler File, ein remote-File sein oder durch einen Webservice geliefert werden. Die Art der referenzierten Geometrie wird attributiv beschrieben. Die korrekte Darstellung dieser Mimetypes muss von der Visualisierungssoftware sichergestellt werden. Zur Festlegung der Positionierung der prototypischen Geometrie im Datenbestand dient eine 3D-Transformationsmatrix. Sie beinhaltet die 16 Parameter für Rotation, Translation und Skalierung der lokalen Geometrie. Die Geometrie ist ein GM_MultiPoint, da so Objekte mit gleichen Eigenschaften mehrfach im Datenbestand gesetzt werden können.
Die Nutzung von Geometriebibliotheken hat einige Vorteile gegenüber der expliziten Repräsentation von Objekten mittels absoluten Koordinaten:
-
Speicher-effizienter als die explizite Geometrie,
-
Umfangreiche Szenen können verarbeitet werden,
-
Flexible Veränderung der Ausprägung von referenzierten Objekten (Austausch von Bibliotheksobjekten).
3D-Transformationsmatrix
Der Datentyp AP_TransformationsMatrix_3D repräsentiert eine allgemeine Transformationsmatrix in der Speicherform eines Vektors. Das Prinzip ist an Szenengraphenkonzepte angelehnt, wie sie im Bereich der Computergraphik gebräuchlich sind. Die Matrix enthält alle erforderlichen Parameter für die Transformation von homogenen Koordinaten aus beliebigen rechtwinkligen Koordinatensystemen der Prototypen in das Koordinatensystem des 3D-Modells.
Realwelt-Szene |
|
3D-Abbildung unter Nutzung von Geometriebibliotheken (Begrenzungspfähle, Laterne) |
3.4. Historie, Versionskonzept
Bei den AFIS-ALKIS-ATKIS-Daten besteht die Anforderung, Versionen und historische Daten zu führen. Der Umfang der Nutzung hängt vom Informationssystem und seiner Anwendung in den Ländern ab. Eine wesentliche Anwendung des Versionskonzeptes stellt das Verfahren zur Nutzerbezogenen Bestandsdatenaktualisierung (NBA) dar.
Das Versionskonzept wurde unter Berücksichtigung folgender Modellierungsgrundsätze erarbeitet:
-
Im Anwendungsschema wird nicht zwischen aktuellen und historischen Versionen unterschieden. Werden historische Versionen dauerhaft gespeichert, spricht man von Vollhistorie. Bei der Vollhistorie müssen grundsätzlich keine eigenen historischen Objektarten gebildet werden, da sämtliche Änderungen nachvollziehbar sind. Zusätzlich kann jedoch optional die Objektart "Historisches Flurstück" geführt werden, wenn historische Daten flurstücksbezogen vorgehalten werden sollen.
-
Historische Objekte und Objektversionen werden in der Migration genauso behandelt, wie aktuelle Objektversionen.
-
Zu jedem Objekt sind ggf. neben den aktuellen auch die historischen Informationen gespeichert (Versionen).
-
Die zum Teil redundante Speicherung von Attributen eines Objekts in mehreren Versionen wird zugunsten eines schnelleren Datenzugriffs auf die entsprechende Version in Kauf genommen.
Das Versionskonzept geht davon aus, dass jedes Fachobjekt einen Identifikator, Attribute und Relationen sowie ein Lebenszeitintervall führt (Entstehungs- und Untergangsdatum). Entstehungs- und Untergangsdatum beinhalten das Datum und die Zeitangabe bis zur Sekunde. Mit dem Eintrag eines Objekts in die Bestandsdaten wird die erste Version des Objekts erzeugt und in einen Objektbehälter eingetragen. Ändert sich aufgrund einer Fortführung eine nicht objektbildende Eigenschaft, so wird eine neue Version des Objekts erzeugt, die historisch gewordene erste Version bleibt jedoch innerhalb des Objektbehälters bestehen, d.h. der Identifikator wird nicht geändert. Die neue Version erhält ein Entstehungsdatum, das gleichzeitig das Untergangsdatum der vorhergehenden Version ist. Die einzelnen Versionen eines Objekts können anhand des Lebenszeitintervalls eindeutig unterschieden werden. Durch Auswertungen der verschiedenen Versionen eines Objekts lassen sich alle Veränderungen bezogen auf einen beliebigen Zeitraum ermitteln.
Werden bei einer Fortführung objektbildende Eigenschaften geändert, führt dies aus fachlicher Sicht zum Untergang eines Objekts. Das Objekt wird historisiert, indem der letzten Version ein Untergangsdatum zugewiesen wird. Das Objekt bleibt weiterhin im Datenbestand erhalten. Zu einem beliebigen Zeitpunkt hat eine Version alle zu diesem Zeitpunkt gültigen Attribute und Relationen. Durch "Klammerung" der Versionen innerhalb eines Objektbehälters bleibt die fachliche Objektsicht stets erhalten. Durch Einführung neuer Referenzversionen des AAA-Modells können Modellelemente wegfallen. Aus Gründen der Abwärtskompatibilität können im Zuge der Migration von der bisherigen auf die neue Referenzversion u.a. neue Objekte entstehen. Dies stellt bzgl. der Historienkontinuität bei Vollhistorie eine Besonderheit dar.
Festlegung objektbildender Eigenschaften im AAA-Modell in UML
Im AAA-Modell in UML sind bei Attributen und Relationen Aussagen untergebracht, die festlegen, wie sich darauf bezogene Fortführungen auswirken. Diese finden sich im jeweils zum/zur Attribut/Relation gehörigen Reiter "Tagged Values" im Feld "AAA objektbildend" in Form der Belegung mit dem Wert True oder False. Alle Eintragungen im offiziell veröffentlichten AAA-Modell wurden durch die AdV vorgenommen. Im Folgenden Erläuterungen zu den getroffenen Festlegungen:
Festlegung im (Reiter AAA / objektbildend zum/zur jew. Attribut/Relation) |
Status der Festlegung im Reiter AAA / objektbildend |
True |
Unabänderliche AdV-Festlegung |
False |
AdV-seitig vorgegebener Rahmen, d.h. es kann länderspezifisch True oder False gesetzt werden*. |
(*Diese Möglichkeit der Unterbringung länderspezifischer Festsetzungen ist im AAA-Modell die absolute Ausnahme).
Festlegung im UML-Modell (Reiter AAA / objektbildend zum/zur jew. Attribut/Relation) |
Auswirkungen der Festlegung von Spalte 1 bei Veränderung betroffener Attribute/Relationen in einer Erhebungs-komponente |
True |
Neues Objekt entsteht (Delete + Insert) |
False |
Neue Objektversion entsteht (Replace) |
Beispiel zum Versionskonzept
Änderung von Attributen
Frau Hilde Huber wird zum Zeitpunkt t1 in ALKIS eingetragen, d.h. es wird ein neues Objekt der Objektart Person gebildet:
Version |
Identifikator |
Zeitintervall |
Name |
Vorname |
hat_Anschrift |
|
Beginn |
Ende |
|||||
Version 1 |
DEBU5t44dFzb70Lg |
t1 |
t∞ |
Huber |
Hilde |
DEBUf88FFgVc761s |
Die Zeitangabe 't∞ ' bedeutet, dass der fachliche Untergang des Objekts bzw. der Version in der Zukunft liegt. Zum Zeitpunkt t2 ändert Frau Huber ihren Namen und heißt nun Meier, d.h. vom Objekt "DEBU5t44dFzb70Lg" der Objektart Person wird aufgrund der Änderung des Attributs Name eine neue Version angelegt:
Version |
Identifikator |
Zeitintervall |
Name |
Vorname |
hat_Anschrift |
|
Beginn |
Ende |
|||||
Version 1 |
DEBU5t44dFzb70Lg |
t1 |
t2 |
Huber |
Hilde |
DEBUf88FFgVc761s |
Version 2 |
DEBU5t44dFzb70Lg |
t2 |
t∞ |
Meier |
Hilde |
DEBUf88FFgVc761s |
Der Zeitpunkt des Untergangs der Version 1 ist identisch mit dem Entstehungsdatum der Version 2 des Objekts. Zum Zeitpunkt t3 verkauft Frau Meier ihr einziges Grundstück. Da sie sonst keine weitere Rolle in ALKIS innehat, geht das Objekt aus fachlicher Sicht unter:
Version |
Identifikator |
Zeitintervall |
Name |
Vorname |
hat_Anschrift |
|
Beginn |
Ende |
|||||
Version 1 |
DEBU5t44dFzb70Lg |
t1 |
t2 |
Huber |
Hilde |
DEBUf88FFgVc761s |
Version 2 |
DEBU5t44dFzb70Lg |
t2 |
t3 |
Meier |
Hilde |
DEBUf88FFgVc761s |
Die Version 2 und damit das gesamte Objekt werden historisiert, nicht gelöscht.
Jede neue Version eines Objektes erhält eigene Relationen, die von ihr ausgehen. Relationen gehen stets von einer bestimmten Version des Objektes aus, d.h. eine Relation von einer Version zu einem anderen Objekt ist nur für diese eine Version gültig. Auf diese Weise werden sämtliche im Objektartenkatalog spezifizierten Kardinalitäten eingehalten.
Dies wird anhand des oben beschriebenen Beispiels erläutert: Frau Hilde Huber, Anschrift Ottostraße 17 in München, wird zum Zeitpunkt t1 in ALKIS eingetragen, d.h. es werden ein Objekt der Objektart Person und ein Objekt der Objektart Anschrift gebildet. Zum Zeitpunkt t2 ändert Frau Huber ihren Namen und heißt fortan Meier. Es wird eine neue Version des Objektes Person angelegt.
In Abbildung 28 repräsentieren die Pfeile eine Relation. Die Richtung des Pfeils gibt gleichzeitig die Richtung der Relation an. Die neue Version des Objektes Person erhält wiederum eine Relation zum entsprechenden Objekt Anschrift. Das Objekt Anschrift selbst wird allerdings nicht versioniert, da die Relation zum Objekt Person unverändert bleibt. Ebenso würde eine neue Version des Objektes Anschrift, z. B. durch Berichtigung nach einem Schreibfehler, keine Änderung des Objektes Person bewirken.
An diesem Beispiel ist auch erkennbar, dass eine Relation stets von der Version über den Identifikator auf den Objektbehälter zeigt und nicht auf eine Version. Der Objektbehälter bildet somit eine Art Klammer um seine verschiedenen Versionen.
Mit dieser Technik können nur Relationen abgebildet werden, die sich auf die jeweils aktuelle Version der beteiligten Objekte beziehen.
Änderung von Relationen
Änderungen bei Relationen führen ebenso zur Versionierung von Objekten wie Attributänderungen. Relationen ändern sich immer dann, wenn das Objekt, auf das die Relation zeigt, neu entsteht, ausgetauscht wird oder wegfällt.
In einem modifizierten Beispiel zur Abbildung 28 wird dies in Abbildung 29 erläutert. Frau Hilde Huber zieht zum Zeitpunkt t3 um, von der Ottostraße 17 in München, zur Platanenallee 34a in Berlin. Das Objekt Anschrift mit der OID "DEBUf88FFgVc761s", auf welches die Relation hat_Anschrift vom Objekt Person ausgehend zeigt, wird ausgetauscht (neue OID "DEBUk41233THjbkO"). Damit ändert sich die betreffende Relation beim Objekt Person und das Objekt Person muss versioniert werden.
Tabellarisch ergibt sich folgendes Bild:
Version |
Identifikator |
Zeitintervall |
Name |
Vorname |
hat_Anschrift |
|
Beginn |
Ende |
|||||
Version 1 |
DEBU5t44dFzb70Lg |
t1 |
t2 |
Huber |
Hilde |
DEBUf88FFgVc761s |
Version 2 |
DEBU5t44dFzb70Lg |
t2 |
t3 |
Meier |
Hilde |
DEBUf88FFgVc761s |
Version 3 |
DEBU5t44dFzb70Lg |
t3 |
t∞ |
Meier |
Hilde |
DEBUk41233THjbkO |
3.5. Abwärtskompatibilität
Um die Versionierung der GeoInfoDok durch die AdV und die Einführung neuer Referenzversionen bei den AdV-Mitgliedsverwaltungen zu erleichtern, können aus dem Datenmodell entfernte Elemente in den Bestandsdaten bei der Einführung einer neuen Referenzversion weiterverwendet werden. Grundsätzliche modellierungstechnische Voraussetzung ist allerdings, dass auf Änderungen verzichtet wird, die eine Abwärtskompatibilität verhindern, was nicht in allen Fällen möglich ist.
Zur Realisierung einer weitgehenden Abwärtskompatibilität zur Vorgängerversion wurden in der GeoInfoDok-Version (7.0.3) einige der Änderungen der Version 7.0 wieder rückgängig gemacht, um die grundsätzliche Möglichkeit zu schaffen, die in der Version 6.0.1 untergegangenen Elemente weiter zu verwenden.
Um klarzustellen, dass bestimmte Informationen nur noch wegen der Abwärtskompatibilität im Anwendungsschema geführt werden, werden die betroffenen Objekt-, Attribut-, Relations- und Wertearten durch Tagged Value im UML-Datenmodell gekennzeichnet.
Zur Kennzeichnung von Informationen, die nur noch wegen der Abwärtskompatibilität im Anwendungsschema enthalten sind, werden daher die betroffenen Objekt-, Attribut-, Relations- und Wertearten in Anlehnung an ISO 19135-1 durch ein Stereotype "retired" [stillgelegt] im UML-Modell gekennzeichnet. Eine Ausgabe der mit "stillgelegt" gekennzeichneten Elemente in den abgeleiteten Objektartenkatalogen ist mit den AdV-Tools möglich. Zusätzlich wird in einem Tagged Value die Version der GeoInfoDok angegeben, bis zu der das stillgelegte Element gültig war ("gültig bis").
Bei der Migration werden alle Objekte/Objektversionen, auch die bereits historisierten, in das Modell der neuen Version migriert. Sofern ein Objekt noch aktuell ist, aber nur noch wegen der Abwärtskompatibilität geführte Modellelemente verwendet, ist die Objektversion - und das gesamte Objekt - mit der Migration zu beenden und ein neues Objekt (oder mehrere) gemäß dem Anwendungsschema der neuen GeoInfoDok-Version zum selben Zeitpunkt neu zu erzeugen.
Beispiel: Ein noch aktuelles Objekt, das derzeit eine "wegfallende" Werteart verwendet. In diesen Fällen werden mit der Migration die aktuellen Objektversionen beendet und neue Objektversionen aktuell, die nicht mehr die "zurückgezogenen" Eigenschaften (Attributarten und Relationsarten) oder Wertearten verwenden.
Die bessere Abwärtskompatibilität bietet auch Möglichkeiten zur Rückmigration von Daten, was auch der föderalen Führung der AAA-Geobasisdaten entgegenkommt und mehr Flexibilität beim Einführungsdatum einer neuen Version ermöglicht. Zu beachten ist, dass eine Rückmigration in Vorgängerversionen der GeoInfoDok mit vertretbarem Aufwand in der Regel nie vollständig erfolgen kann.
Lückenlose historische Recherchen und Datenabgaben
Bei den Daten haltenden Stellen besteht neben einer verbesserten Abwärtskompatibiliät zudem der Bedarf, dass historische Objekte (d.h. historische Objektversionen und geschlossene Objektbehälter) auch in Nachfolgeversionen der GeoInfoDok enthalten bleiben. Dabei wurden folgende Anforderungen berücksichtigt:
-
Historische Abfragen für die Erzeugung von Bestandsdatenauszügen und NBA sind möglich und liefern dieselben fachlichen Ergebnisse wie vor der Migration.
-
Bestehende NBA-Verfahren werden ohne erneute Grundausstattung weiter unterstützt.
-
Eine Abgabe an Nutzer, die ggf. noch in der alten GeoInfoDok-Version (FinV, Grundbuch, Statistik, Bundesnetzagentur, etc.) arbeiten, ist in der alten Struktur möglich.
Auswirkungen der Abwärtskompatibilität auf die NAS
Die Festlegungen zur besseren Abwärtskompatibilität wirken sich auf die NAS folgendermaßen aus:
-
In den neuen XML-Schemadateien tauchen die alten (gelöschten) Elemente in unveränderter Form noch auf, d.h. die Schemadateien werden lediglich durch die neu hinzugekommenen Elemente ergänzt
-
Die XML-Validierung mittels Schemadatei unterscheidet nicht zwischen "retired" und aktuellen Elementen.Gleichwohl gelten hier die Regeln der GeoInfoDok (Modell und Hauptdokument). Beispiel: in der 7.0.3 darf bei der OA_Schleuse das Attribut "Bezeichnung" nicht mehr erscheinen.
-
Annahme: Nur die jeweils aktuelle Referenzversion ist implementiert. Daraus werden abgelöste Referenzversionen bedient. Bei der Einführung weiterer Versionen muss noch geklärt werden, wie weit zurück die Abwärtskompatibilität mit vertretbarem Aufwand realisiert werden kann.
Auswirkungen der Abwärtskompatibilität auf die Datenführung
Die Festlegungen zur besseren Abwärtskompatibilität wirken sich auf die Datenführung folgendermaßen aus:
-
In der Implementierung der GeoInfoDok-Referenzversion dürfen Elemente, die mit "retired" gekennzeichnet sind, nicht mehr in Ausgaben (Bestandsdatenauszüge, NAS, Ausgabeprodukte) dieser Referenzversion vorkommen, ausgenommen entsprechende Rückmigrationsausgaben.
-
Solange Datenbestände geführt werden, die auf zurückgezogenen (retired) Elementen basieren, können historisierte Daten aus der Datenbank nicht gelöscht werden.
-
Ein Benutzungsauftrag bzw. eine NBA lässt anhand seines Namensraumes erkennen, ob er, bzw. sie eine rückmigrierte Benutzung oder eine aktuelle ist.
Änderungen bei Benutzungsaufträgen, wie z.B. der Nutzerbezogenen Bestandsdatenaktualisierung
-
Die Einführung von "retired"-Elementen wird nur bei den AAA-Bestandsdaten berücksichtigt, nicht aber bei Elementen zur Datenführung, wie z.B. dem NBA-Verfahren. Gleichwohl werden die Änderungen im Folgenden beschrieben, die für das NBA-Verfahren notwendig sind, um die Abwärtskompatibilität zu realisieren:Die AX_BenutzergruppeNBA wurde um ein Attribut <abgabeversion> mit einer Enumerationsliste der zulässigen Versionen als Pflichtattribut erweitert.
Abbildung 32. Neue Attributart 'abgabeversion' zur Selektion von Objekten verschiedener GeoInfoDok-Versionen -
Die Enumerationsliste besteht aus den Informationen der alten und aktuellen Referenzversion, hier "6.0.1" und "7.1.2". Es ist die volle Versionsnummer anzugeben und nicht nur der Namespace.
-
Für Bestandsdatenauszüge reicht der Benutzungsauftrag im jeweiligen Namespace, um Daten im alten Format abgeben zu können.
-
Objektarten, die mit Einführung einer neuen Version "retired" werden, sind nur bis zur Vorgängerversion gültige Objektarten. Beispiel: OA_Grenzuebergang wird mit der Version 7.1.2 "retired", dann ist diese OA nur bis zur letzten Version, 6.0.1, gültig. In der OA wird ein entsprechendes "Tagged Value" gesetzt.
-
In der NAS-XSD sind alle Objektarten enthalten, unabhängig davon, ob "retired" oder nicht. Eine Unterscheidung ist nicht möglich. Mit der Benutzung in einer Vorgängerversion der GeoInfoDok werden
-
auch sämtliche OA selektiert, die mit der Selektionsversion retired wurden oder schon waren
-
alle optionalen Elemente der neuen Version rückmigriert oder weggelassen; Rückmigrationsregeln sind zu erstellen und zu beachten.
-
-
Rückmigration ist nur möglich, solange Abwärtskompatibilität gewährleistet ist. Bei neuen Vollversionen (Änderung der ersten Stelle) ist die Abgabe in die Vorgängerversion nur eingeschränkt möglich. Die rückmigrierbaren und nicht-rückmigrierbaren Elemente sind anzugeben (z.B. in einer Migrationstabelle).
-
Bei der Einführung neuer Vollversionen mit ggf. vielen nicht-abwärtskompatiblen Änderungen ist aus fachlicher Sicht zu prüfen, ab wann die Abgabe in das alte System nicht mehr sinnvoll möglich ist (z.B. neue Werteart bei Pflichtattribut ist nicht rückmigrierbar, da es keine 9998 mehr gibt).
3.6. Qualitäts- und Metadaten
Das gemeinsame AFIS-ALKIS-ATKIS-Datenmodell sieht die Erfassung und Führung von Qualitäts- und Metadaten auf der Grundlage der ISO-Normen:
-
ISO 19109 Geographic Information - Rules for Application Schema,
-
ISO 19113 Geographic Information - Quality Principles,
-
ISO 19114 Geographic Information - Quality Evaluation Procedures und
-
ISO 19115-1 Geographic Information - Metadata
vor.
Die Qualitätsdaten werden dabei nach nicht quantifizierbaren Überblicksinformationen (Zweck, Verwendung und Historie) und quantifizierbaren Informationen (den Datenqualitäts-Elementen Vollständigkeit, logische Konsistenz, geometrische, inhaltliche und zeitliche Genauigkeit) unterschieden.
Die Angabe der Qualitätsinformationen erfolgt als Metadaten gemäß der Norm ISO 19115 und darüber hinaus für quantitative, aggregierte Qualitätsangaben bei Bedarf in Form von detaillierten Qualitäts-Bewertungsprotokollen gemäß Norm ISO 19114, was jedoch nicht Bestandteil der GeoInfoDok ist und daher hier nicht weiter spezifiziert wird.
Beispiel für eine Qualitätsangabe zu einem Punktort mit den folgenden Eigenschaften:
-
Datenerhebung 'Aus Katastervermessung ermittelt (1000)'
-
Erhebungsdatum '01.04.1990'
-
Erhebungsstelle Katasteramt X
-
Berechnungsdatum '01.01.1994'
-
keine Angabe zur berechnenden Stelle
-
Genauigkeitswert 0,022 m
-
Genauigkeitsstufe 2000
-
Vertrauenswürdigkeit 1200
Diese Qualitätsangaben werden in der NAS wie folgt kodiert:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
<?xml version="1.0" encoding="UTF-8"?>
<AX_DQPunktort xmlns="http://www.adv-online.de/namespaces/adv/gid/7.1" xmlns:gmd="http://www.isotc211.org/2005/gmd" xmlns:gml="http://www.opengis.net/gml/3.2"
xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:gco="http://www.isotc211.org/2005/gco" xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xsi:schemaLocation="http://www.adv-online.de/namespaces/adv/gid/7.1 http://repository.gdi-de.org/schemas/adv/nas/7.1/aaa.xsd">
<herkunft>
<gmd:LI_Lineage>
<gmd:processStep>
<gmd:LI_ProcessStep>
<gmd:description>
<AX_LI_ProcessStep_Punktort_Description>Erhebung</AX_LI_ProcessStep_Punktort_Description>
</gmd:description>
<gmd:dateTime>
<gco:DateTime>1990-04-01T00:00:00Z</gco:DateTime>
</gmd:dateTime>
<gmd:processor>
<gmd:CI_ResponsibleParty>
<gmd:organisationName>
<gco:CharacterString>Katasteramt X</gco:CharacterString>
</gmd:organisationName>
<gmd:role>
<gmd:CI_RoleCode codeList="http://schemas.opengis.net/iso/19139/20070417/resources/Codelist/gmxCod
elists.xml#CI_RoleCode" codeListValue="processor">processor</gmd:CI_RoleCode>
</gmd:role>
</gmd:CI_ResponsibleParty>
</gmd:processor>
<gmd:source>
<gmd:LI_Source>
<gmd:description>
<AX_Datenerhebung_Punktort>1000</AX_Datenerhebung_Punktort>
</gmd:description>
</gmd:LI_Source>
</gmd:source>
</gmd:LI_ProcessStep>
</gmd:processStep>
<gmd:processStep>
<gmd:LI_ProcessStep>
<gmd:description>
<AX_LI_ProcessStep_Punktort_Description>Berechnung</AX_LI_ProcessStep_Punktort_Description>
</gmd:description>
<gmd:dateTime>
<gco:DateTime>1994-01-01T00:00:00Z</gco:DateTime>
</gmd:dateTime>
</gmd:LI_ProcessStep>
</gmd:processStep>
</gmd:LI_Lineage>
</herkunft>
<genauigkeitswert>
<gmd:DQ_RelativeInternalPositionalAccuracy>
<gmd:result>
<gmd:DQ_QuantitativeResult>
<gmd:valueUnit xlink:href="urn:adv:uom:m"/>
<gmd:value>
<gco:Record xsi:type="gml:doubleList">0.022</gco:Record>
</gmd:value>
</gmd:DQ_QuantitativeResult>
</gmd:result>
</gmd:DQ_RelativeInternalPositionalAccuracy>
</genauigkeitswert>
<genauigkeitsstufe>2000</genauigkeitsstufe>
<vertrauenswuerdigkeit>1200</vertrauenswuerdigkeit>
</AX_DQPunktort>
Vorgaben:
-
Gemäß Abschnitt 4.4.2 (letzter Spiegelstrich) sowie Abschnitt 4.4.4 (erster Absatz) TBD: Sind das immer noch die passenden Referenzen? und dem darin referenzierten ISO/TS 19139 8.5.4 ist für Enumerationen das spezifische Element aus dem AAA-Fachschema, welches gco:CharacterString substituiert, zu verwenden.
-
Wird eine Quelle zu einem Prozesschritt angegeben, so wird diese in den LI_ProcessStep eingebettet, um eine Zuordnung zu ermöglichen. Die Elemente des UML-Modells werden somit bei der Ableitung der XML-Schemadateien in eine ISO-konforme Struktur überführt (das UML-Modell enthält Vereinfachungen, die im Shape-Change-Prozess ISO-konform abgebildet werden).
-
Sofern eine Stelle zu einer Erhebung oder Berechnung angegeben wird, ist als Rolle "processor" anzugeben.
-
In der Rollenangabe ist ein Codelistenverweis erforderlich, der gemäß ISO/TS 19139 8.5.5 eine URL sein muss. Im Beispiel ist eine URL auf ein Code-List-Dictionary im OGC-Schemarepository angegeben. Dies kann alternativ - wie bei Schemaverweisen - auch ein anderer gültiger Verweis auf ein Code-List-Dictionary sein.
-
Der Name der verantwortlichen Stelle wird im Klartext angegeben.
-
Bei den Einheiten des Genauigkeitswerts sind nur die in der GeoInfoDok 8.2.2 angegebenen Einheiten erlaubt.
-
Gemäß Beispiel in ISO/TS 19139 9.7.4.1.4 d) soll bei gco:Record der Datentyp in xsi:type angegeben werden. Im Fall von Koordinatengenauigkeiten soll dies "doubleList" aus dem GML-Schema sein, da Genauigkeitsangaben ein oder mehrere Werte enthalten können. Es wird die Einheit "m" verwendet, gemäß Abschnitt 8.2.3 "urn:adv:uom:m".
Metadaten sind "Daten über Daten" und dienen der Beschreibung der Geodaten hinsichtlich nutzerrelevanter Aspekte zur Bewertung der Eignung der Daten und des Zugriffs auf dieselben. ISO unterscheidet etwa 400 optionale, obligatorische und bedingt obligatorische Metadatenelemente, gegliedert in inhaltliche Einheiten (entities) sowie in die folgenden Abschnitte (sections):
-
Identifikation,
-
Datenqualität,
-
Fortführung,
-
Raumbezogene Eigenschaften,
-
Referenzsystem,
-
Ausdehnung,
-
Inhalt,
-
Anwendungsschema,
-
Signaturenkatalog,
-
Vertrieb,
-
Nutzungsbedingungen.
Qualitäts- und Metadaten können gemäß ISO für einen Datenbestand (Sammlung von logisch zusammengehörigen Objekten), für Berichtsgruppen (Teilmengen eines Datenbestandes) und für einzelne Objekte angegeben werden.
Der gemeinsame AFIS-ALKIS-ATKIS-Metadatenkatalog wird weiter unten näher beschrieben.
3.7. Objektartenkataloge
Die Struktur der Objektartenkataloge ist durch die ISO-Norm 19110 Feature Cataloguing Methodology vorgegeben. Aufgrund der Objektorientierung ist es auch möglich, die Methoden im Objektartenkatalog zu beschreiben, wovon im AAA-Datenmodell bislang allerdings nur selten Gebrauch gemacht wurde. Die Vorgaben zur Struktur eines Objektartenkatalogs sind logisch getrennt zu sehen von der Beschreibung dieser Objektarten in einem Datenmodell. Daher ist das Schema "AAA-Objektartenkatalog" außerhalb des AAA-Anwendungsschemas eigenständig modelliert. Das gleiche gilt für die Vorgaben zur Beschreibung der Ausgaben, Signaturen und Präsentationsvorschriften. Das gemeinsame Anwendungsschema erweitert diese Strukturen im Paket AAA-Katalog um einige Inhalte, die für die Anwendungen AFIS, ALKIS und ATKIS zusätzlich benötigt werden.
Kataloge werden zur einfacheren Implementierung ausschließlich vollständig versioniert und ausgetauscht.
Die Objektartenkataloge werden mit Hilfe eines Skripts direkt aus dem UML-Datenmodell abgeleitet und als editier- und lesbare Formate PDF und HTML veröffentlicht.
3.8. Ausgabekatalog
Die GeoInfoDok wird in der Modellierungssprache UML originär in Enterprise Architect (EA) modelliert. Im Rahmen der Modularisierung wurde auch der AFIS-ALKIS-ATKIS-Ausgabekatalog (AAA_AK) aus dem AFIS-ALKIS-ATKIS-Anwendungschema (Paket NAS-Operationen) exportiert und kann damit auch eine eigenständige Versionierung erfahren. Neben den Schemadateien des AAA-Anwendungsschemas (NAS-Operationen.xsd, aaa.xsd, AAA-Fachschema.xsd, AAA-Basisschema.xsd) gibt es auch die des Ausgabekataloges (AAA-Ausgabekatalog.xsd).
Der AFIS-ALKIS-ATKIS-Ausgabekatalog (AAA_AK) beschreibt die Inhalte der Standardausgaben der AdV. Insbesondere sind dies die AFIS-Einzelpunktnachweise, die AFIS-Punktlisten und die beschreibenden ALKIS-Standardausgaben und ALKIS-Ausgaben.
Im AAA_AK sind die Regeln zur Auswertung der Bestandsdaten in verbaler Form hinterlegt, damit in den Ergebnissen immer 'menschen’lesbare Informationen entstehen. Die weitere Verwendung dieser Daten in den zugehörigen Standardprodukten wird dann in den nicht formalisierten Signaturenkatalogen für AFIS und ALKIS beschrieben.
Der AAA_AK ist auch in der Form eines Objektartenkatalogs veröffentlicht.
3.9. Signaturenkataloge
Bei den Signaturenkatalogen wird zwischen den 'formalisierten' und 'nicht formaltisierten' Signaturenkatalogen unterschieden.
Die nicht formalisierten Signaturenkataloge beinhalten die Darstellungsregeln für die beschreibenden Ausgaben aus dem AFIS-ALKIS-ATKIS-Ausgabekatalog (AAA_AK).
Mit den formalisierten Signaturenkataloge wurden die Signaturierungsregeln für graphische Ausgaben in ein Objektmodell gefasst. Die Grundlagen für die Modellierung befinden sich im Anwendungsschema AFIS-ALKIS-ATKIS-Signaturenkatalog (AAA_SK). Der Signaturenkatalog kann aufgrund der Modularisierung ebenfalls eigenständig versioniert werden.
3.9.1. Nicht formalisierte Signaturenkataloge (nFSK)
Die nicht formalisierten Signaturenkataloge sind für die AdV-Produkte, die i.d.R. in der Ausgabe keinen Raumbezug nutzen, notwendig.
Hierzu zählen:
-
ALKIS
-
Flurstücksnachweis (ggf. mit Bodenschätzung)
-
Flurstücks- und Eigentümernachweis (ggf. mit Bodenschätzung)
-
Grundstücksnachweis
-
Bestandsnachweis
-
Amtliche Flächenstatistik
-
Fortführungsnachweis und Fortführungsmitteilungen
-
Gebäudenachweis
-
Liegenschaftskarte (Rahmen)
-
-
AFIS
-
AFIS-Punktlisten
-
AFIS-Einzelpunktnachweise
-
Die bisher verwendeten Teile A bis G sind in den jeweiligen Signaturenkatalog zusammengefasst. Ergänzt werden diese durch Standbögen (für die Darstellungen der Positionen auf dem jeweiligen Ausgabemedium) und Muster der Präsentationsausgaben für die AdV-Standardprodukte. Im Falle der Liegenschaftskarte werden die Karteninhalte mit Hilfe des formalisierten Signaturenkatalaog erzeugt.
3.9.2. Formalisierter Signaturenkatalog (fSK)
Die Vorgaben zur Struktur eines Signaturenkatalogs (SK) haben übergeordneten Charakter und sind deshalb logisch getrennt zu sehen von der Beschreibung von fachlichen Objektarten in einem Datenmodell. Daher ist das Schema "AAA-Signaturenkatalog" außerhalb des AAA-Anwendungsschemas eigenständig modelliert.
Kern der Modellierung ist eine SK-Definitionssprache, Map-Definition-Language ("MDL", ursprünglich "SDL" genannt), welche alle SK-Definitionen in einer lesbaren, aber dennoch automatisiert verarbeitbaren Form darstellen kann. Ein zentrales MDL-Repository speichert den Stand des SKs in MDL und definiert damit die Referenzversion des SK.
Ein MDL-Compiler leitet aus dem in MDL definierten SK automatisch SK-Dokumente in HTML und PDF ab. Ein weiterer Output des MDL-Compilers ist eine Repräsentierung des SK in "SK-XML", einer XML-Sprache, die im Wesentlichen denselben Inhalt wie MDL bedient. Die Repräsentierung in SK-XML soll es ermöglichen, daraus einfach externe Repräsentierungen des SK zu generieren, um handelsübliche GIS-Software zu unterstützen. Die Umsetzungen aus SK-XML sollen durch externe Akteure erfolgen.
Da MDL und SK-XML naturgemäß strukturell verwandt sind, liegt es nahe, beide auf der Basis eines gemeinsamen, in UML definierten, Objektmodells zu entwickeln.
3.10. Prozesse, Vorgänge und Aktivitäten
3.10.1. Grundsätze
Im Rahmen der Zuständigkeit des amtlichen Vermessungswesens sind die Aufgaben Erhebung, Qualifizierung, Führung (Ersteinrichtung, Fortführung), Benutzung und Übertragung von Daten auszuführen. Jede dieser Aufgaben äußert sich in einem oder mehreren Prozessen. Es gibt Erhebungs-, Qualifizierungs-, Führungs-, Benutzungs- und Transferprozesse.
Die Geoinformationen des amtlichen Vermessungswesens bestehen aus den originären Bestandsdaten und den temporären Datenbeständen der Erhebungsdaten, Fortführungsdaten, Ausgabedaten und Transferdaten.
Die Projektsteuerung im AAA-Basisschema steuert den Ablauf aller Prozesse in Form von Vorgängen und Aktivitäten, womit vollständige Geschäftsprozesse beschrieben werden können. Sie stellt lediglich eine optionale Rahmenvorgabe dar, die inhaltlich durch die länderspezifischen Geschäftsprozesse zu untersetzen ist. In der Abbildung 35 werden die Prozesse und Daten der Geoinformationen des amtlichen Vermessungswesens dargestellt. Die im Rahmen des AdV-Projektes "Modellierung der Geoinformationen des amtlichen Vermessungswesens" fachlich zu modellierenden Bestandteile werden von einer gestrichelten Linie umrahmt.
Zu einem Prozess gehören mehrere aufeinander aufbauende Aktivitäten, die zu Vorgängen zusammengefasst und fachlich gegliedert werden können. Zur Beschreibung der Prozesse (Vorgänge und Aktivitäten) werden folgende Sprachmittel verwendet:
-
Aktivitäten als Bestandteil der UML-Klassen,
-
Textliche Beschreibung der Bearbeitungsschritte,
-
Die graphische Darstellung der Vorgänge erfolgt entsprechend der UML- Notation in Sequenzdiagrammen
-
Auswerteregeln des AAA-Ausgabekataloges zur Beschreibung der Selektions- und Auswertefunktionalität bei der Erstellung von Standardausgaben
3.10.2. Vorgang und Aktivität
Für eine vollständige Anwendungsbeschreibung sind Vorgänge und Aktivitäten zu definieren, die Daten in funktionelle Abhängigkeiten setzen und das dynamische Verhalten der Anwendung definieren. Vorgänge sind den einzelnen Prozessen im AAA-Anwendungsschema zugeordnet. Dies kann aus der Abbildung 36 entnommen werden.
Ein Vorgang beinhaltet die Darstellung von Bearbeitungsschritten der Prozesse Qualifizierung, Führung, Benutzung und Übertragung, in denen auf verschiedene Aktivitäten verwiesen wird.
Eine Aktivität beschreibt das Verhalten eines Objekts und besteht aus einer Sequenz von Anweisungen. Den Anstoß dazu erhält ein Objekt durch eine Nachricht, die durch Eingaben des Nutzers oder durch Aktivitäten anderer Objekte ausgelöst werden (Eingabeparameter). Das Ergebnis der Aktivität wird in Form von Ausgabeparametern bereitgestellt. Aktivitäten werden objektbezogen definiert und sind im UML-Modell Bestandteil einer Klasse.
3.10.3. Prozesse des AFIS-ALKIS-ATKIS-Anwendungsschemas
Mit einem Prozess wird ein Quelldatenbestand in einen Zieldatenbestand überführt. Der Benutzungsprozess beispielsweise überführt die Bestandsdaten in temporäre Ausgabedaten.
Zur Steuerung der verschiedenen Prozesse werden spezielle Klassen gebildet, die Steuerungsparameter für den Ablauf von Prozessen beinhalten, wie z. B. "AX_Benutzungsauftrag" im Benutzungsprozess des AAA-Anwendungsschemas.
3.10.3.1. Erhebungsprozess
Quelldaten werden mit den bekannten geodätischen Mess- und Erkundungsmethoden in der realen Welt erhoben oder aus kartographischen Darstellungen und anderen Unterlagen erfasst. Die Zieldaten des Erhebungsprozesses sind die objektstrukturierten Erhebungsdaten, die eine Grundlage zur Fortführung der amtlichen Geoinformationen bilden.
3.10.3.2. Qualifizierungsprozess
Im Qualifizierungsprozess werden die digitalen, objektstrukturierten Erhebungsdaten nach einer Qualifizierung in Fortführungsdaten überführt. Er dient der Qualitätssicherung und stellt sicher, dass die Fortführungsdaten den Qualitätsanforderungen entsprechen.
Die Zieldaten des Qualifizierungsprozesses sind die Fortführungsdaten.
3.10.3.3. Führungsprozess
Im Führungsprozess sind Ersteinrichtung und Fortführung der Geoinformationen zusammengefasst, wobei die Ersteinrichtung als Sonderfall der Fortführung betrachtet werden kann. Beim Führungsprozess werden die Fortführungsdaten (Daten und Metadaten) durch Anwendung geeigneter Methoden in den Bestand überführt.
Die Zieldaten des Führungsprozesses sind die Bestandsdaten.
Die für die Einrichtung und Fortführung notwendigen Funktionalitäten sind im Rahmen der Austauschschnittstelle in Abschnitt 5.1.1, darüber hinaus gehende implizite Funktionen eines Führungssystems in Abschnitt 5.3 beschrieben. Das konzeptuelle Fachmodell für die Fortführung von ALKIS sowie die exakten Abläufe bei der Fortführungsverarbeitung sind in der Dokumentation zur Objektart "AX_Fortfuehrungsauftrag" enthalten. Ferner zeigt ein Sequenzdiagramm eine beispielhafte Illustration der Beschreibung zum "AX_Fortfuehrungsauftrag".
3.10.3.4. Benutzungsprozess
Benutzungsprozesse überführen Bestandsdaten in Ausgabedaten entsprechend den fachlichen Vorgaben
-
in Form von Bestandsdatensätzen zur universellen Weiterverarbeitung beim Nutzer,
-
als aufbereitete Bestandsdaten mit festgelegtem Inhalt in einem einheitlichen Erscheinungsbild des amtlichen Vermessungs- und Katasterwesens (Präsentationsausgaben, Auswertungen etc.) sowie
-
als Änderungsdaten nach der Fortführung (Nutzerbezogene Bestandsdatenaktualisierung-NBA).
Eine Ausgabe kann Bestandsobjekte, historisierte Objekte (aus Gründen der Abwärtskompatibilität) sowie temporär erzeugte Objekte beinhalten.
Zur Strukturierung der Ausgabedaten und für Elementangaben, die nicht aus den Attributarten des Bestandes entnommen werden können, die aber für eine Ausgabe notwendig sind, werden temporäre Objektarten gebildet (z.B. AX_K_Fortfuehrungsfall_FM). Temporäre Objektarten sind keine AA_Objekte, sondern Datentypen, die im AAA-Ausgabekatalog beschrieben sind. Sie besitzen keinen Identifikator und kein Lebenszeitintervall. Sie werden auch nicht im Bestand geführt.
Die temporäre Prozessobjektart "AX_Benutzungsauftrag" des Anwendungsschemas enthält wesentliche Angaben zur Steuerung des Benutzungsprozesses, wie Umfang der Ausgabe, Antragsnummer, Anlassart, Benutzungsparameter, Ausgabename usw. und wird zu Beginn des Benutzungsprozesses erzeugt. Durch die Attributart "Benutzungsparameter" werden die erforderlichen Parameter für die Kosten- und Gebührenberechnung, die außerhalb der Geoinformationen des amtlichen Vermessungswesens vorgenommen wird, bereitgestellt. Die übrigen für eine Ausgabe notwendigen temporären Objektarten entstehen durch Methoden innerhalb des Benutzungsprozesses aus den Bestandsobjektarten.
Die temporären Objektarten, insbesondere die temporären Ausgabe- Objektarten, werden so modelliert, dass Relationen innerhalb einer Ausgabe vermieden werden.
Ausgabeobjektarten können je nach Anforderung auch unter Beachtung des Signaturenkatalogs präsentiert werden. Die Verbindungen und der Informationsfluss zwischen dem Objektartenkatalog, dem Ausgabekatalog, dem Signaturenkatalog und den Ausgaben können aus der nachfolgenden Schemadarstellung entnommen werden.
Demnach werden z. B. für eine Präsentationsausgabe die Objektarten der Bestandsdaten an Hand einer definierten Abfrageabfolge aufbereitet zu einer temporären Ausgabeobjektart entwickelt. Anschließend erfolgt unter Berücksichtigung der erforderlichen Signaturierung und des Präsentationslayouts eine Ausgabe am Bildschirm bzw. als Druckausgabe. Möglich ist aber auch die Abgabe von nicht aufbereiteten Ausgabedatensätzen, die von Nutzern unter Verwendung eigener Layoutvorgaben aufbereitet werden können.
3.10.3.5. Transferprozess
Übertragungsprozesse treten bei der Übernahme von Daten Dritter in Form von Fortführungsdaten und bei der Abgabe von Ausgabedaten an Kunden auf. Übertragungsprozesse zur Datenübernahme empfangen Ausgaben der Systeme Dritter einschließlich Transferfunktionen in Form von Transferdaten. Übertragungsprozesse zur Datenabgabe ergänzen Ausgabedaten um Transferfunktionen und erzeugen aus ihnen Transferdaten für Systeme Dritter.
3.11. Projektsteuerung
Die im Paket "AAA_Projektsteuerung" definierten Klassen beschreiben einen Strukturrahmen zur Beschreibung einer Projektsteuerung. Die Klassendiagramme "AA_Antrag", "AA_Projektsteuerungskatalog" und "AA_Meilenstein" zeigen das Konzept der modellierten Projektsteuerung.
3.11.1. Antrag
Dreh- und Angelpunkt der Projektsteuerung ist die Objektart AA_Antrag. Diese Objektart realisiert eine "Mini-Antragsverwaltung", d.h. eine Schnittstelle zur externen Antragsverwaltung. Dadurch wird es möglich, bei einem Eintrag in der externen Antragsverwaltung (Geschäftsbuch) direkt einen Bezug zu diesem Antrag (mit Raumbezug) zu generieren.
Das Antragsobjekt verwaltet außerdem die Wiedervorlage des Antrags und unterstützt die Überwachung der Projektsteuerungs-Objekte. Mit dem Raumbezug kann nach bestehenden Prozessen gesucht werden, um konkurrierende Anträge zu ermitteln oder um andere benachbarte Anträge bei der Bearbeitung zu berücksichtigen. Die fachliche Reihenfolge konkurrierender Anträge ist durch den Sachbearbeiter festzulegen. Das Antrags-Objekt wird mit dem Projektsteuerungs-Objekt (AA_Projektsteuerung) verbunden, um die Zuordnung des Antrags zu einem oder mehreren Projektsteuerungs-Objekten festzulegen und um die nicht zulässigen Kombinationen zu überwachen. Weiterhin steuert und überwacht das Projektsteuerungs-Objekt die korrekte Abwicklung der Vorgänge im Teilprozess "fachtechnische Qualifizierung". Die Fortführungsanlässe werden beim Projektsteuerungs-Objekt geführt.
Der Vorgang ist Teil einer Projektsteuerung und setzt sich aus einzelnen Aktivitäten zusammen. Die Vorgänge stellen in sich abgeschlossene Arbeitsschritte dar. Ein vorzugebender Arbeitsablauf ("Workflow") legt die Reihenfolge und Abhängigkeiten der Vorgänge und deren Arbeitsschritte fest. Die Vorgänge werden in Gruppen zusammengefasst und in einer bestimmten Reihenfolge nacheinander bzw. nebeneinander bearbeitet. Die Entscheidung über den Abschluss des einzelnen Vorganges wird im Status (Meilenstein) dokumentiert.
3.11.2. Projektsteuerungskatalog
Der Projektsteuerungskatalog definiert die innerhalb eines Projektsteuerungs-Objektes dieser Art erlaubten Fortführungsanlässe. Er beinhaltet die Projektsteuerungs- und Vorgangsarten. Die Projektsteuerungsart bündelt Projektsteuerungs-Objekte, die eine gemeinsame Charakteristik aufweisen. Analoges gilt für die Vorgangsart.
3.11.3. Meilenstein
Hierbei handelt es sich um einen Datentyp, der zu einem Vorgang usw. den aktuellen Zustand und die Verantwortlichkeiten vermerkt.
Eine anwendungsbezogene Erläuterung der Projektsteuerung des AAA-Basisschemas für das Fachschema ALKIS befindet sich in der GeoInfoDok in den "Erläuterungen zu ALKIS". Weitere Einzelheiten und Zusammenhänge können hieraus entnommen werden.
4. Die Kodierung des NAS-Schemas
In Kapitel 2 sind die Grundlagen und Zusammenhänge für die mit dieser Dokumentation zu beschreibenden Geoinformationen erläutert. Das dort festgelegte Referenzmodell stellt unter anderem auch den Bedarf für den Datenaustausch dar. Soweit es erforderlich ist, den Datenaustausch als AdV-Standard einheitlich zu definieren, enthält dieses Kapitel die Festlegungen zu den zu verwendenden Austauschschnittstellen. Die in der Folge aufgeführten XML-Schemadateien sind im GDI-DE-Schema-Repository unter http://repository.gdi-de.org/schemas/adv/nas/ verfügbar.
4.1. Normbasierte Austauschschnittstelle (NAS)
Die Normbasierte Austauschschnittstelle (NAS) wird verwendet, wenn Geoinformationen ausgetauscht werden sollen, die im gemeinsamen AFIS-ALKIS-ATKIS-Anwendungsschema modelliert wurden. Dabei kann es sich um Informationen handeln, die in ihrer Struktur den gespeicherten Datenbeständen, einschließlich der Zusatzdaten (Präsentationsobjekte, Kartengeometrieobjekte, vgl. Kapitel 2) entsprechen, oder um Ausgaben auf Basis dieser Bestandsdaten (Bestandsdatenauszug, NBA).
Informationen aus daraus abgeleiteten Sichten auf diese Datenbestände (z.B. AFIS-, ALKIS-, oder ATKIS-spezifische Ausgabeobjektarten) werden über ein eigenes XML Schema kodiert.
Dasselbe gilt unverändert für die weiteren Kataloge (Objektartenkatalog und Signaturenkatalog), für die ebenfalls XML Schemata spezifiziert sind. Die GeoInfoDok macht jedoch keine Vorgaben zur Kodierung von Datenbeständen, bei denen der Objektbezug völlig verloren geht (z.B. rein graphisch strukturierte Daten) oder Daten, die nach einem anderen Basisschema zu definieren sind (z.B. DXF-Daten).
Entsprechend wird sie dort eingesetzt, wo der Anwendungsschwerpunkt nach Anforderung des Nutzers auf
-
der Originalität der Daten,
-
der vollen Auswertbarkeit und
-
der differenzierten Fortführbarkeit
liegt.
4.2. Normen und Standards
Die Standards AFIS, ALKIS und ATKIS der AdV sind in dieser Dokumentation in konzeptueller Form auf der Grundlage der Norm ISO 19109 Rules for Application Schema beschrieben. Dies bedeutet insbesondere:
-
Modellierung in UML, derzeit mit dem Softwarewerkzeug Enterprise Architect,
-
Einhaltung der Regelungen von ISO/TS 19103 und ISO 19109 für die Verwendung von UML,
-
Verwendung von ISO 19107 (und damit implizit auch ISO 19111), ISO 19115-1, und ISO 19123 sowie
-
Automatisierte Ableitung und Darstellung der Objektartenkataloge gemäß ISO 19110.
Die automatisierte Ableitung der Schnittstelle für den Austausch von AFIS-, ALKIS- und ATKIS-Objekten, die NAS, vervollständigt dieses Bild.
ISO 19118 Encoding definiert zu diesem Zweck u.a. ein Rahmenwerk für die Erstellung von so genannten Encoding Rules zur Ableitung von Schnittstellen-Definitionen für den Datenaustausch aus einem UML-Anwendungsschema. Das in ISO 19118 Kapitel 8 definierte Rahmenwerk für Encoding Rules wird für die NAS angewendet (Level-1-Konformität mit ISO 19118).
Für die NAS wird ein zweistufiger Codierungsprozess angewandt (siehe Abbildung 41):
-
Im ersten Schritt wird aus dem konzeptuellen, implementierungsplattformunabhängigen AAA-Anwendungsschema skriptgestützt ein Implementierungsschema in UML für ein GML-Anwendungsschema abgeleitet. Alle Elemente des Implementierungsschemas sind zu den Vorgaben aus ISO 19136 Annex E oder - im Falle von Metadatenelementen - zu ISO/TS 19139 konform. ISO 19136 ist identisch mit dem OGC Standard Geography Markup Language, kurz GML.
-
Im zweiten Schritt wird das Implementierungsschema nach den Encoding Rules von ISO 19136 Annex E mit den Erweiterungen nach GML 3.3 Kapitel 12 und - im Falle von Metadatenelementen - ISO/TS 19139 in ein GML Anwendungsschema überführt.
Hierbei wird darauf zurückgegriffen, dass die im AAA-Anwendungsschema verwendeten Typen aus ISO/TS 19103, ISO 19107, ISO 19111 und ISO 19123 durch ISO 19136 (GML) und dem darauf aufbauenden GML Application Schema - Coverages in standardisierter XML-Schema-Implementierung vorliegen. Für ISO 19115-1 liegt derzeit noch keine standardisierte Codierung vor und es wird unverändert das XML Schema aus ISO/TS 19139 verwendet, was bei der geringfügigen Nutzung von ISO 19115-1 keine konzeptuellen Probleme bedeutet.
Da das AAA-Anwendungsschema und somit auch die NAS neben der Codierung von Fachobjekten auch Operationen auf einem System zur Haltung von Bestandsdaten umfasst (Fortführen, Einrichten, Sperren/Entsperren von Objekten, Reservieren von Fachkennzeichen, Erfragen von Ausgabeprodukten einschließlich der Nutzerbezogenen Bestandsdatenaktualisierung), werden die GML-Objektarten unter Verwendung von Elementen der zu GML komplementären OGC-Spezifikationen Web Feature Service (WFS) und Filter Encoding Standard (FES) in entsprechende, grundsätzlich Web-Service-fähige, Operationen eingebettet. In diesem Sinne ist eine AFIS-ALKIS-ATKIS-Datenhaltung mit einem gekapselten Web Feature Server zu vergleichen, der zusätzlich AFIS-ALKIS-ATKIS-spezifische Anforderungen berücksichtigt.
Gemäß den in Abschnitt 3.1 genannten Grundlagen verfolgt die AdV mit der Implementierung von AFIS, ALKIS und ATKIS das Ziel, Grundlagen für die gemeinsame, ganzheitliche und fachübergreifende Nutzung von Geodaten zu schaffen. In diesem Sinne soll soweit wie möglich auf bestehende oder absehbare Standardfunktionalitäten von Anwendungssoftware zurückgegriffen werden.
In der NAS wird entsprechend auf die Spezifikation von AdV-spezifischen Lösungen für das Codieren von Daten soweit wie möglich verzichtet. Da die internationalen Standards an einigen Stellen für die speziellen Anforderungen der AdV präzisiert werden müssen, ist der Einsatz des Web Feature Service und Filter Encoding nur mit AFIS-ALKIS-ATKIS-spezifischen Erweiterungen möglich.
Es ist wichtig festzuhalten, dass das plattformunabhängige, konzeptuelle Modell im AAA-Anwendungsschema vollständig beschrieben ist. Bei der Abbildung auf spezifische Implementierungsmodelle (wie z.B. XML-Repräsentierungen) werden auch zukünftig Anpassungen an den IT/GI-Mainstream erforderlich werden.
Über die genannten Normen der Normfamilie ISO 19100 hinaus werden zur Definition der NAS folgende Standards herangezogen (siehe Normative Referenzen für die genauen Quellen):
-
Unified Modeling Language
-
XML
-
XML Schema
-
XLink
-
XPath
-
OGC Web Feature Service
-
OGC Filter Encoding
-
OGC Web Services Common Specification
-
OGC Geography Markup Language — Extended schemas and encoding rules
-
OGC GML Application Schema - Coverages
Dadurch, dass GML-Anwendungsschemata auf standardisierte XML-Komponenten, z.B. für Geometrietypen, zurückgreifen und es in GML Regeln gibt, wie XML Schema bei der Definition eines Anwendungsschemas zu verwenden ist, kann auch generische GML-Software - sofern sie die verwendeten XML-Komponenten implementiert hat - durch Analyse des GML-Anwendungsschemas der NAS AFIS-ALKIS-ATKIS-Objekte grundsätzlich verarbeiten und syntaktisch interpretieren. Dies gilt auch dann, wenn die Software zuvor kein Wissen über die NAS und AFIS-ALKIS-ATKIS besessen hat.
Mit dem von der NAS verwendeten GML-Profil werden aus diesem Grunde auch Anforderungen an die Fähigkeiten von Software spezifiziert und dokumentiert. Bei der Festlegung des Profils wurde auch die Zielsetzung berücksichtigt, dass dieses Profil auch über AFIS, ALKIS und ATKIS hinaus Anwendungsanforderungen abdecken soll und sich von einer AdV-internen Festlegung zu einer breiter akzeptierten Festlegung entwickelt.
Durch die Spezifikation der NAS in Form von Operationen auf einer Bestandsdatenhaltung und nicht als reines "Datenformat" sind die GML-Objekte in der NAS i.d.R. in die XML-Elemente der Operationsaufrufe und -ergebnisse eingebettet. Im Fall des Bestandsdatenauszugs zum Beispiel ist die Menge der GML-Objekte, d.h. das GML-Dokument, in das NAS-Ergebnisdokument eingebettet und kann aus diesem auf einfache Weise erkannt und extrahiert werden.
4.3. Kodierungsprozess
Die Norm ISO 19118 beschreibt den durchzuführenden Kodierungs- und Dekodierungsprozess in allgemeiner Form folgendermaßen:
Der Prozess geht dabei von folgenden Rahmenbedingungen aus:
-
Es existiert ein formal (z.B. in UML) beschriebenes Anwendungsschema.
-
Auf der Basis von Umwandlungsregeln (Schema Conversion Rules) und ggf. Steueranweisungen bzw. -parametern werden die Informationen des UML-Anwendungsschemas in eine oder mehrere XML-Schemadateien überführt.
-
In gleicher Weise werden die auf dem Anwendungsschema beruhenden Anwendungsdaten (Objekt-Instanzen) mit Hilfe von Umwandlungsregeln (Instance Conversion Rules) in eine XML-Datei überführt, die in ihrem Aufbau den Definitionen der XML-Schema-Datei entspricht.
Im Kontext der NAS wird die Umwandlung des AAA-Anwendungsschemas (UML) in das GML Anwendungsschema der NAS (XML Schema) mit den folgenden Mitteln durchgeführt:
-
Umwandlung des Anwendungsschemas mit dem NAS-Tool in das Implementierungsschema (unter Verwendung der Java-Klasse NasTransformer_7)
-
Anwendung der Encoding Rules mit dem Open-Source-Tool ShapeChange über das NAS-Tool und Erzeugung der NAS-Schemadateien.
-
Die ShapeChange Konfigurationsdatei wurde hierzu an die AAA-spezifischen Modellrahmenbedingungen angepasst.
-
4.4. NAS Encoding Rules
Im Folgenden werden die "NAS Encoding Rules" beschrieben. Die Struktur erfüllt die Anforderungen aus ISO 19118 Kapitel 8 und richtet sich zur einfachen Vergleichbarkeit an ISO 19118 Annex A aus.
ISO 19118 legt in Kapitel 8 Anforderung an Encoding Rules fest. Eine Encoding Rule beschreibt Abbildungsregeln mit denen Daten aus einer Eingangsdatenstruktur (Instanzen gemäß dem AAA-Anwendungsschema in Enterprise Architect) in eine Ausgabedatenstruktur (XML-Datei gemäß NAS) überführt werden können. Eine Encoding Rule deckt folgende Themen ab:
-
Voraussetzungen
-
Anwendungsschema
-
Zeichensatz und unterstützte Sprachen
-
Austausch-Metadaten (exchange metadata)
-
Identifikatoren
-
Updatemechanismen
-
-
Eingangsdatenstruktur
-
Ausgabedatenstruktur
-
Abbildungsregeln
-
Beispiele
4.4.1. Voraussetzungen
Anwendungsschema
Das AAA-Anwendungsschema wurde auf der Basis der Regeln für Anwendungsschemata aus ISO/TS 19103 und ISO 19109 entwickelt.
Zur größeren Klarheit werden im Anwendungsschema die folgenden zusätzlichen Stereotypen verwendet:
-
«FeatureType» im Sinne der Definition in ISO 19136 Annex E,
Zusätzlich werden UML Tagged Values wie in ISO 19136 E.2.1 spezifiziert im Modell verwendet sowie zwei weitere UML Tagged Values "xsdEncodingRule" und "reverseRoleNAS" unterstützt. Hierbei gelten die folgenden Regeln:
-
version, targetNamespace und xmlns: aktuelle Werte gemäß der Version des AAA-Anwendungsschemas, nur im AAA-Anwendungsschema-Paket
-
gmlProfileSchema: Verweis auf die Datei des GML-Profils, nur im AAA-Anwendungsschema-Paket
-
xsdDocument: Dateiname der XML-Schema-Datei, wird neben dem AAA-Anwendungsschema-Paket auch bei den Paketen des AAA-Basisschema, des AAA-Fachschema und der NAS-Operationen gesetzt
-
Bei Klassen werden die folgenden UML Tagged Values gesetzt:
-
noPropertyType: "true" bei «FeatureType»; "false" bei «DataType» und «Union»
-
byValuePropertyType: "false" bei «FeatureType», «DataType» und «Union>
-
isCollection: "false" bei «FeatureType», «DataType» und «Union>
-
asDictionary: "true", nur bei «CodeList»
-
-
Bei Attributen und Assoziationsrollen werden die folgenden Tagged Values gesetzt:
-
sequenceNumber
-
inlineOrByReference: "byReference" bei «FeatureType»-wertigen Eigenschaften, sonst "inline"
-
isMetadata: "true" bei allen Qualitätsangaben, sonst "false"; zu Qualitätsangaben werden alle Typen gezählt, die mit einer der folgenden Zeichenketten beginnen: "LI_", "DQ_", "AX_DQ", "AX_LI"
-
Zeichensatz und unterstützte Sprachen
Wie in ISO 19118 A.2.3 spezifiziert, soll grundsätzlich der Universal Character Set (UCS) von "ISO-10646-1" als Zeichenvorrat verwendet werden. Dieser ist identisch mit dem Unicode Character Repertoire.
Als Character Encoding für NAS-Daten soll einheitlich "UTF-8" (UTF = UCS Transformation Format) verwendet werden. "UTF-8" ist auch der Standardwert in XML, falls eine Encoding-Angabe fehlt. Gemäß der Vorgaben des IT-Planungsrates [KOSIT-01] wird eine Teilmenge von Unicode als Zeichensatz verwendet.
Sprache ist Deutsch ("de") oder Sorbisch (Niedersorbisch bzw. Obersorbisch).
Exchange Metadata
Im Zuge der Modellierung der Aufträge und Ergebnisse werden jeweils die erforderlichen Exchange Metadata modelliert und mit der automatischen Umsetzung nach XML Schema überführt.
Identifikatoren
Identifikatoren sind in der NAS nur auf der Ebene der Fachobjekte definiert, d.h. in allen XML-Elementen, die Typen repräsentieren, welche eine Unterklasse von AA_Objekt sind. Bei diesen sind die Identifikatoren stets anzugeben (mit Ausnahme der weiter unten definierten Fälle). Identifikatoren an allen übrigen Elementen werden überlesen und nicht beachtet.
Die Identifikatoren an Fachobjekten sind stets im Sinne von UUIDs zu verstehen, d.h. sie sind innerhalb der "AFIS-ALKIS-ATKIS-Application-Domain" eindeutig.
Der AAA-Identifikator besteht stets aus 16 Zeichen. Der Aufbau wird in Abschnitt 3.3.9 beschrieben.
Updatemechanismen
Ein Updatemechanismus im Sinne von ISO 19118 Kapitel 8 wird über die NAS-Operationen unterstützt.
4.4.2. Eingangsdatenstruktur
Das AAA-Anwendungsschema verwendet einige Konstruktionen in UML, die in den Abbildungsregeln von ISO 19136 Annex E, GML 3.3 Kapitel 12 und ISO/TS 19139 nicht unterstützt werden, bzw. die für die Codierung vereinfacht werden sollen. Daher erfolgt eine skriptgestützte Umsetzung des konzeptuellen AAA-Anwendungsschemas in UML in ein Implementierungsschema (siehe oben TBD: Genaue Referenz?). Hierzu wird ein neues Paket "NAS" als Kopie des Pakets "AFIS-ALKIS-ATKIS Anwendungsschema" angelegt und transformiert.
Das Skript nimmt die folgenden Änderungen vor:
-
Multiple Vererbung: Weder ISO 19136 / GML 3.3 noch ISO/TS 19139 unterstützen in den Abbildungsregeln multiple Vererbung, das AAA-Modell verwendet diese jedoch in Mixin-Klassen (z.B. AP_GPO, AX_Katalogeintrag). Die Mixin-Klassen werden aufgelöst:
-
Alle Attribute werden in die nächsten in der NAS codierten Subtypen kopiert.
-
Alle Relationen zu den Mixin-Klassen werden ebenfalls jeweils auf die nächsten in der NAS codierten Subtypen kopiert. Dabei wird der Rollenname durch Anhängen des Klassennamens geändert, um die Eindeutigkeit der Eigenschaftsnamen zu gewährleisten.
-
Die «Type»-Klassen werden gelöscht.
-
-
Nicht navigierbare Assoziationsrollen werden
-
navigierbar gesetzt
-
sofern nicht vorhanden mit dem Namen "inversZu_" und den Namen der inversen Rolle versehen
-
mit einer minimalen Kardinalität von "0" versehen
-
der UML Tagged Value "reverseRoleNAS" wird auf "true" gesetzt
-
-
Die Modellelemente, die Inhalte besitzen, die nicht in die NAS umgesetzt werden, werden bei der Ableitung des Implementierungsmodells für den Datenaustausch entfernt.
-
Pakete:
-
"AAA Versionierungsschema"
-
-
Attribute:
-
"AA_Objekt.identifikator"
-
-
Klassen:
-
"AA_ObjektOhneRaumbezug"
-
"AX_Fortfuehrung"
-
"AX_Datenbank"
-
"AX_Operation_Datenbank"
-
"AX_TemporaererBereich"
-
"AX_NeuesObjekt"
-
"AX_GeloeschtesObjekt"
-
"AX_AktualisiertesObjekt"
-
"AX_Fortfuehrungsobjekt"
-
-
-
Die Modellelemente, die Inhalte besitzen, die auf spezifische Weise in die NAS umgesetzt werden sollen, werden entsprechend angepasst:
-
Die Eigenschaften von AA_PMO und AA_Objekt werden wie bei Mixin-Klassen (siehe oben TBD: Genaue Referenz?) auf "AD_PunktCoverage" und "AD_GitterCoverage" übertragen, die konzeptuellen Attribute "AA_PMO.ausdehnung", "AD_PunktCoverage.geometrie" und "AD_PunktCoverage.werte" gelöscht. Zusätzlich werden Vererbungsbeziehungen auf "CV_DiscreteGridPointCoverage" bzw. "CV_DiscretePointCoverage" gesetzt.
-
Die folgenden Typen erhalten ein neues Attribut und werden von den konzeptuellen Typen (TS-Klassen) entkoppelt:
-
"TA_PointComponent.position : GM_Point"
-
"TA_CurveComponent.position : GM_Curve"
-
"TA_SurfaceComponent.position : GM_Surface"
-
"TA_MultiSurfaceComponent.position : GM_Object" (die Werte müssen entweder GM_Surface oder GM_MultiSurface sein)
-
-
Die Assoziation mit der Rolle "TA_MultiSurfaceComponent.masche" wird entsprechend gelöscht.
-
Die folgenden Attribute erhalten einen neuen Typ:
-
"AU_Punkthaufenobjekt.position : GM_MultiPoint"
-
"AU_KontinuierlichesLinienobjekt.position : GM_Curve"
-
"AU_Flaechenobjekt.position : GM_Object"
-
"AG_Flaechenobjekt.position : GM_Object"
-
"AG_Punktobjekt.position : GM_Point"
-
"AU_Objekt.position : GM_Object"
-
"AG_Objekt.position : GM_Object"
-
"AU_GeometrieObjekt_3D.position : GM_Object"
-
"AU_MehrfachLinienObjekt_3D.position : GM_Object"
-
"AU_MehrfachFlaechenObjekt_3D.position : GM_Object"
-
"AU_UmringObjekt_3D.position : GM_MultiCurve"
-
"AU_PunkthaufenObjekt_3D.position : GM_MultiPoint"
-
"AP_TransformationsMatrix_3D.parameter : doubleList"
-
"AX_DQOhneDatenerhebung.herkunft : LI_Lineage"
-
"AX_DQMitDatenerhebung.herkunft : LI_Lineage"
-
"AX_DQErhebung3D.herkunft3D : LI_Lineage "
-
"AX_DQPunktort.herkunft : LI_Lineage"
-
"AX_DQDachhoehe.herkunft : LI_Lineage"
-
"AX_DQBodenhoehe.herkunft : LI_Lineage"
-
"AX_Schwereanomalie_Schwere.wert : Measure"
-
"AX_DQSchwere.genauigkeitswert : Measure"
-
"AX_Schwere.schwerewert : Measure"
-
"AX_VertikalerSchweregradient.genauigkeitVertikalerSchweregradient : Measure"
-
"AX_VertikalerSchweregradient.wertVertikalerSchweregradient : Measure"
-
"AX_Leitung.spannungsebene : Measure"
-
"AX_Sperrauftrag.uuidListe : URI"
-
"AX_Entsperrauftrag.uuidListe : URI"
-
"ExceptionFortfuehrung.bereitsGesperrteObjekte : URI"
-
"ExceptionFortfuehrung.nichtMehrAktuelleObjekte : URI"
-
"ExceptionAAAFortfuehrungOderSperrung.bereitsGesperrteObjekte : URI"
-
"ExceptionAAAFortfuehrungOderSperrung.nichtMehrAktuelleObjekte : URI"
-
"ExceptionAAAEntsperren.uuidListe : URI"
-
"DCP.HTTP : URI"
-
"DCP.email : URI"
-
"AX_Fortfuehrungsergebnis.fortfuehrungsnachweis : Any"
NoteDer Datentyp wird im Implementierungsschema der NAS auf "Any" geändert (dies wird in GML zu gml:AbstractObject), da der in den NAS nur nachrichtlich referenzierte Fortführungsnachweis im Ausgabekatalog spezifiziert ist und dieser separat versioniert wird. Dies verhindert, dass NAS und das Implementierungsschema des Ausgabekatalog wechselseitig voneinander abhängig sind. Alle Werte des Attributs "fortfuehrungsnachweis" müssen eine Kodierung von AX_Fortfuehrungsnachweis aus einer von der AdV veröffentlichten Version des Implementierungsschemas des Ausgabekatalogs sein.
-
-
Verweise in den Projektsteuerungskatalog werden als XLink-Verweis realisiert (über MapEntries in der ShapeChange-Konfiguration der NAS):
-
"AA_Antrag.art : AA_Antragsart"
-
"AA_Projektsteuerung.art : AA_Projektsteuerungsart"
-
"AA_Vorgang.art : AA_Vorgangsart"
-
"AA_Aktivitaet.art : AA_Aktivitaetsart"
-
-
Die Klassen des Projektsteuerungskatalogs werden gelöscht:
-
"AA_Antragsart"
-
"AA_Projektsteuerungsart"
-
"AA_Vorgangsart"
-
"AA_Aktivitaetsart"
-
"AA_Projektsteuerungskatalog"
-
"AA_AktivitaetInVorgang"
-
"AA_VorgangInProzess"
-
"AA_Dokumentationsbedarf"
-
"AA_DurchfuehrungAktivitaet"
-
"AA_ProzesszuordnungAktivitaet"
-
-
Als Folge der obigen Anpassungen können außerdem die folgenden Typen gelöscht werden:
-
"AA_Liniengeometrie"
-
"AA_Flaechengeometrie"
-
"AU_Geometrie"
-
"AG_Geometrie"
-
"AU_Geometrie_3D"
-
"AA_Punktgeometrie"
-
"AA_Punktgeometrie_3D"
-
"AA_MehrfachLinienGeometrie_3D"
-
"AA_MehrfachFlaechenGeometrie_3D"
-
"AA_PunktLinienThema"
-
"AX_LI_ProcessStep_OhneDatenerhebung"
-
"AX_LI_ProcessStep_MitDatenerhebung"
-
"AX_LI_ProcessStep_Punktort"
-
"AX_LI_ProcessStep_Bodenhoehe"
-
"AX_LI_ProcessStep_Dachhoehe"
-
"AX_LI_ProcessStep3D"
-
"Acceleration"
-
"AccelerationGradient"
-
Voltage
-
"AD_ReferenzierbaresGitter"
-
"AD_Wertematrix"
-
"AA_UUID"
-
-
Bei allen Klassen wird das UML Tagged Value "xsdEncodingRule" gesetzt: "iso19136_2007" außer bei Typen, die mit einer der Zeichenketten "AX_DQ", "AX_LI" oder "AX_Datenerhebung" beginnen; bei diesen wird "iso19139_2007" verwendet.
-
-
Hinweis: Sofern Attributen und Relationsrollen der Mixin-Klasse in Subtypen aus einem anderen Anwendungsschema kopiert werden, dann folgt daraus, dass in der NAS die XML-Elemente der kopierten Attribute / Relationsrollen in dem XML-Namensraum des Subtypen und nicht in dem XML-Namesraum der Mixin-Klasse definiert werden.
Beispiel: Die Ausgabeobjektart AX_Liegenschaftskarte erbt die beiden Attributarten "koordinatenangaben" und "enthaelt" von der Mixin-Klasse AA_Objektliste aus dem AAA-Anwendungsschema. Durch das beschriebene Vorgehen werden die XML-Elemente für die beiden Attribute im Namensraum des Ausgabekatalogs ('http://www.adv-online.de/namespaces/adv/aaa-ak/2.0') und nicht im Namensraum des AAA-Anwendungsschemas ('http://www.adv-online.de/namespaces/adv/gid/7.1') definiert.
Das Instanzenschema wird auf der Basis des Implementierungsschemas von ISO 19136 E.2.2 übernommen.
4.4.4. Schema-Abbildungsregeln
Relevante Fundstellen für die Schema-Abbildungsregeln sind: ISO 19136 E.2.4 mit den Erweiterungen aus GML 3.3 Kapitel 12 und - für Klassen mit dem UML Tagged Value xsdEncodingRule mit dem Wert "iso19139_2007" - ISO/TS 19139 Kapitel 8.
Die Werte des UML Tagged Value "reverseRoleNAS" werden im XML Schema in appinfo-Annotationen an dem Element ausgegeben, das der Assoziationsrolle entspricht.
Das von der AdV spezifizierte Schema für WFS-Erweiterungen codiert die in Abschnitt 5.1.3 beschriebenen Erweiterungen.
Die importierten, von Dritten definierten und verwalteten Schemata (OWS Common 1.1, GML 3.2, GML 3.3, Xlink 1.1, ISO/TS 19139:2007, WFS 2.0 und Filter Encoding 2.0 werden in den jeweiligen kanonischen Schema-Repositories referenziert.
Abbildungsregeln für Instanzen
Dieser Abschnitt beschreibt die Abbildung des Instanzenmodells in entsprechende XML-Elemente. Das Ergebnis der Abbildung ist ein valides XML-Dokument (NAS-Dokument). Entsprechend gezippte XML-Dokumente sind ebenfalls gültige NAS-Dokumente. Als Komprimierungsverfahren zugelassen sind "zip" und "gzip".
Die Datei enthält:
-
Den XML-Header, der fest ist: "<?xml version="1.0" encoding="UTF-8" ?>". Die Verwendung von "UTF-8" wird für das Encoding vorgeschrieben.
-
Das Root-Element aus einer Auftrags- oder Ergebnis-XSD-Datei mit einem Verweis auf den AdV-Namespace "http://www.adv-online.de/namespaces/adv/gid/version" und die XSD-Datei.
-
Elemente in Übereinstimmung mit der referenzierten XSD-Datei.
Jedes Objekt im Instanzenschema wird in ein entsprechendes Element überführt. Das passende Element trägt denselben Namen wie die Klasse, zu der das Objekt gehört. Das "gml:id"-Attribut, das den Identifikator trägt, wird gesetzt.
Jede Eigenschaft des Objekts, d.h. jedes Attribut und jede Rolle in einer Assoziation, wird entsprechend der in den Schema-Abbildungsregeln definierten Abbildung auf XML-Elemente abgebildet, i.d.R. in ein lokales Element mit dem Namen des Attributs oder der Rolle.
Codierung von Identifikatoren in der NAS
Der AAA-Identifikator besteht stets aus 16 Zeichen. Der Aufbau wird in Abschnitt 3.3.9 beschrieben.
In der NAS ist der AAA-Identifikator im XML-Attribut gml:id zu codieren. Beispiel:
<AX_Gebaeude gml:id="DEST123412345678">
<!-- ... -->
</AX_Gebaeude>
Um die dokumentenweite Eindeutigkeit des gml:id-Attributs zu gewährleisten, wird die Angabe immer dann um Entstehungsdatum/-zeit ergänzt, wenn mehrere Versionen eines Objekts in einem XML-Dokument vorkommen. Dies kommt insbesondere in den folgenden Fällen vor:
-
In einem Bestandsdatenauszug werden mehrere Versionen eines Objekts selektiert.
-
Ein Objekt wird in einem Fortführungsauftrag mit mehreren Fortführungsfällen mehrfach geändert.
-
In der Einrichtung werden auch historische Objektversionen migriert.
Datum und Uhrzeit werden hierbei in 16 Zeichen ohne Trennzeichen kodiert, damit sie den Bedingungen einer XML ID genügen, also in der folgenden Form: CCYYMMDDThhmmssZ.
Beispiel:
<AX_Gebaeude gml:id="DEST12341234567820010101T110000Z">
<!-- ... -->
</AX_Gebaeude>
<!-- ... -->
<AX_Gebaeude gml:id="DEST12341234567820070313T125420Z">
<!-- ... -->
</AX_Gebaeude>
Zusätzlich zur gml:id ist der Identifikator ebenfalls in der in ISO 19136 vordefinierten Objekteigenschaft, gml:identifier, zu codieren. Hierbei gelten die folgenden Regeln:
-
Als codeSpace ist "http://www.adv-online.de/" zu verwenden.
-
Es wird stets der Identifikator (also ohne Entstehungsdatum/-zeit) angegeben.
-
Der Identifikator wird als globaler Identifikator, d.h. als URN (siehe unten TBD: Genaue Referenz?) codiert.
Beispiel:
<AX_Gebaeude gml:id="DEST123412345678">
<gml:identifier codeSpace="http://www.adv-online.de/">
urn:adv:oid:DEST123412345678
</gml:identifier>
<!-- ... -->
</AX_Gebaeude>
In der NAS kommen zwei Arten von Verweisen auf Objekte vor:
-
Verweise von einem Objekt auf ein anderes Objekt werden stets als XLink repräsentiert. Innerhalb der NAS sind Verweise auf andere AAA-Objekte ausnahmslos über URNs auszudrücken. Uniform Resource Names (URNs) dienen als global eindeutige, persistente, Speicherort-unabhängige Identifikatoren. URNs von AAA-Identifikatoren beginnen alle mit "urn:adv:oid:", ergänzt durch den Identifikator.
Beispiel: "urn:adv:oid:DEST123412345678". -
Verweise aus einem Selektionskriterium auf ein bestimmtes Objekt über einen Identifikator (fes:ResourceId/@rid). Hier ist stets der Identifikator ohne URN-Kontext anzugeben. In einigen Fällen ist hierbei zur Aktualitätsprüfung ebenfalls das 16-stellige Entstehungsdatum/-zeit ohne Trennzeichen anzugeben. Die entsprechenden Fälle werden in Abschnitt 5.1 spezifiziert.
Codierung von Geometrieeigenschaften in der NAS
Auf die Kodierung der Orientierung von Linien (Curves) wurde im AAA-Basisschema verzichtet. Da die Richtung einer Linie aber fallweise (z.B. Fließrichtung von Gewässern) eine Bedeutung hat, muss a) die Erfassung in positiver Richtung erfolgen und b) sichergestellt werden, dass diese Richtung im Zuge der Verarbeitung und Speicherung unverändert bleibt. Damit kann davon ausgegangen werden, dass die Linienorientierung in der NAS immer positiv ist und es einer gesonderten Kennzeichnung nicht bedarf.
Bei Flächenumringen liegt die begrenzte Fläche gemäß ISO 19107 immer zur Linken der in positiver Richtung orientierten begrenzenden Linien.
Um die NAS möglichst einfach zu gestalten, wird Geometrie ausschließlich redundant ausgetauscht. NAS-Daten aufnehmende Programmsysteme müssen Topologie bzw. gemeinsame Geometrienutzung selbst erkennen - sofern sie sich für diese Information interessieren. Die Einstiegshürde für die Nutzung von AFIS-ALKIS-ATKIS-Daten wird dadurch möglichst niedrig gehalten.
Das "Erkennen" von Geometrieteilung wird durch die folgenden Punkte - auf möglichst einfache Weise - definiert.
Topologische Objekte und solche mit gemeinsam genutzter Geometrie können Themen zugeordnet werden. Topologische Beziehungen und gemeinsame Geometrienutzung sind nur innerhalb eines Themas möglich. Ein Thema ist immer auf eine Modellart beschränkt.
Damit zwei Geometrien identisch sind, müssen sie identische Definitionen in einem <Point> bzw. einer <Curve> besitzen, ein identischer Geometrieverlauf allein ist bei Linien nicht ausreichend.
Zur Erläuterung folgende Themendefinition für die Modellart Basis-DLM
<AX_Themendefinition>
<name>Tatsächliche Nutzung Basis-DLM</name>
<art>1000</art>
<objektart>AX_Hafenbecken</objektart>
<objektart>AX_StehendesGewaesser</objektart>
<objektart>AX_Meer</objektart>
<objektart>AX_Fliessgewaesser</objektart>
<objektart>AX_Gewaesserachse</objektart>
<objektart>AX_Wohnbauflaeche</objektart>
<objektart>AX_IndustrieUndGewerbeflaeche</objektart>
<objektart>AX_Halde</objektart>
<objektart>AX_Bergbaubetrieb</objektart>
<objektart>AX_TagebauGrubeSteinbruch</objektart>
<objektart>AX_FlaecheBesondererFunktionalerPraegung</objektart>
<objektart>AX_SportFreizeitUndErholungsflaeche</objektart>
<objektart>AX_Friedhof</objektart>
<objektart>AX_FlaecheGemischterNutzung</objektart>
<objektart>AX_Landwirtschaft</objektart>
<objektart>AX_Wald</objektart>
<objektart>AX_Gehoelz</objektart>
<objektart>AX_Heide</objektart>
<objektart>AX_Moor</objektart>
<objektart>AX_Sumpf</objektart>
<objektart>AX_UnlandVegetationsloseFlaeche</objektart>
<objektart>AX_Strassenverkehr</objektart>
<objektart>AX_Platz</objektart>
<objektart>AX_Bahnverkehr</objektart>
<objektart>AX_Flugverkehr</objektart>
<objektart>AX_Schiffsverkehr</objektart>
<objektart>AX_Bahnstrecke</objektart>
<objektart>AX_Strassenachse</objektart>
<objektart>AX_Fahrbahnachse</objektart>
<objektart>AX_Fahrwegachse</objektart>
<modellart>Basis-DLM</modellart>
<dimension>2000</dimension>
</AX_Themendefinition>
Zur Erläuterung hier ein Beispiel bestehend aus 42003 AX_Strassenachse, 41006 AX_FlaecheGemischterNutzung und 41008 AX_SportFreizeitUndErholungsflaeche, welche aufgrund der Themendefinition in gemeinsamen Positionen über identische Koordinatenpaare verfügen.
<!-- ... -->
<AX_Strassenachse gml:id="DETHTL2500005JpT">
<!-- ... -->
<modellart>
<AA_Modellart>
<advStandardModell>Basis-DLM</advStandardModell>
</AA_Modellart>
</modellart>
<istTeilVon xlink:href="urn:adv:oid:DETHTL25000056OE"/>
<position>
<gml:Curve gml:id="A285">
<gml:segments>
<gml:LineStringSegment>
<gml:posList>640244.590 5648317.260 640186.230 5648414.980</gml:posList>
</gml:LineStringSegment>
<gml:LineStringSegment>
<gml:posList>640186.230 5648414.980 640127.410 5648513.460</gml:posList>
</gml:LineStringSegment>
</gml:segments>
</gml:Curve>
</position>
<!-- ... -->
</AX_Strassenachse>
<!-- ... -->
<AX_FlaecheGemischterNutzung gml:id="DETHTL2500005Lu4">
<!-- ... -->
<modellart>
<AA_Modellart>
<advStandardModell>Basis-DLM</advStandardModell>
</AA_Modellart>
</modellart>
<position>
<gml:Surface gml:id="A3EN">
<gml:patches>
<gml:PolygonPatch>
<gml:exterior>
<gml:Ring>
<gml:curveMember>
<gml:Curve gml:id="A3EO">
<gml:segments>
<gml:LineStringSegment>
<gml:posList>640186.230 5648414.980 640127.410 5648513.460</gml:posList>
</gml:LineStringSegment>
</gml:segments>
</gml:Curve>
</gml:curveMember>
<gml:curveMember>
<gml:Curve gml:id="A3EP">
<gml:segments>
<gml:LineStringSegment>
<gml:posList>640127.410 5648513.460 640224.910 5648555.150</gml:posList>
</gml:LineStringSegment>
</gml:segments>
</gml:Curve>
</gml:curveMember>
<gml:curveMember>
<gml:Curve gml:id="A3EQ">
<gml:segments>
<gml:LineStringSegment>
<gml:posList>640224.910 5648555.150 640276.083 5648460.442</gml:posList>
</gml:LineStringSegment>
</gml:segments>
</gml:Curve>
</gml:curveMember>
<gml:curveMember>
<gml:Curve gml:id="A3ER">
<gml:segments>
<gml:LineStringSegment>
<gml:posList>640276.083 5648460.442 640186.230 5648414.980</gml:posList>
</gml:LineStringSegment>
</gml:segments>
</gml:Curve>
</gml:curveMember>
</gml:Ring>
</gml:exterior>
</gml:PolygonPatch>
</gml:patches>
</gml:Surface>
</position>
<!-- ... -->
</AX_FlaecheGemischterNutzung>
<!-- ... -->
<AX_SportFreizeitUndErholungsflaeche gml:id="DETHTL2500005KVW">
<!-- ... -->
<modellart>
<AA_Modellart>
<advStandardModell>Basis-DLM</advStandardModell>
</AA_Modellart>
</modellart>
<position>
<gml:Surface gml:id="A2R7">
<gml:patches>
<gml:PolygonPatch>
<gml:exterior>
<gml:Ring>
<gml:curveMember>
<gml:Curve gml:id="A2R8">
<gml:segments>
<gml:LineStringSegment>
<gml:posList>640244.590 5648317.260 640186.230 5648414.980</gml:posList>
</gml:LineStringSegment>
</gml:segments>
</gml:Curve>
</gml:curveMember>
<gml:curveMember>
<gml:Curve gml:id="A2R9">
<gml:segments>
<gml:LineStringSegment>
<gml:posList>640186.230 5648414.980 640276.083 5648460.442</gml:posList>
</gml:LineStringSegment>
</gml:segments>
</gml:Curve>
</gml:curveMember>
<gml:curveMember>
<gml:Curve gml:id="A2RA">
<gml:segments>
<gml:LineStringSegment>
<gml:posList>640276.083 5648460.442 640329.780 5648363.250</gml:posList>
</gml:LineStringSegment>
</gml:segments>
</gml:Curve>
</gml:curveMember>
<gml:curveMember>
<gml:Curve gml:id="A2RB">
<gml:segments>
<gml:LineStringSegment>
<gml:posList>640329.780 5648363.250 640244.590 5648317.260</gml:posList>
</gml:LineStringSegment>
</gml:segments>
</gml:Curve>
</gml:curveMember>
</gml:Ring>
</gml:exterior>
</gml:PolygonPatch>
</gml:patches>
</gml:Surface>
</position>
<!-- ... -->
</AX_SportFreizeitUndErholungsflaeche>
<!-- ... -->
Identität bei Linien wird stets auf der Ebene der "GM_Curve" untersucht. Sie ist gegeben, wenn alle Positionen der Geometriedefinition in Lage und Reihenfolge sowie verwendeter Interpolationsart identisch sind. Hierbei ist auch eine Umkehrung der Reihenfolge erlaubt.
Zwei Positionen sind identisch, wenn ihr Abstand kleiner als die vorzugebende Koordinatenauflösung ist. In AFIS-ALKIS-ATKIS ist diese für metrische Lagekoordinaten auf 3 Nachkommastellen (mm) festgelegt. Diese Festlegung gilt unabhängig von der tatsächlichen Genauigkeit der Koordinaten.
Zur Erläuterung werden die beiden Situationen aus Abbildung 44 beispielhaft codiert. Zuerst die linke Situation (ohne Linienteilung):
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
<!-- ... -->
<AX_Flurstueck gml:id="DEBY000000000001">
<!-- ... -->
<position>
<gml:Surface srsName="urn:adv:crs:DE_DHDN_3GK3" gml:id="_1">
<gml:patches>
<gml:PolygonPatch>
<gml:exterior>
<gml:Ring gml:id="_2">
<gml:curveMember>
<gml:Curve gml:id="_3">
<gml:segments>
<gml:LineStringSegment>
<gml:posList>601085.954 5943996.138</gml:posList>
<gml:posList>601085.954 5943998.138</gml:posList>
</gml:LineStringSegment>
</gml:segments>
</gml:Curve>
</gml:curveMember>
<gml:curveMember>
<gml:Curve gml:id="_4">
<gml:segments>
<gml:LineStringSegment>
<gml:posList>601085.954 5943998.138</gml:posList>
<gml:posList>601078.954 5943998.138</gml:posList>
</gml:LineStringSegment>
</gml:segments>
</gml:Curve>
</gml:curveMember>
<gml:curveMember>
<gml:Curve gml:id="_5">
<gml:segments>
<gml:LineStringSegment>
<gml:posList>601078.954 5943998.138</gml:posList>
<gml:posList>601078.954 5943996.138</gml:posList>
</gml:LineStringSegment>
</gml:segments>
</gml:Curve>
</gml:curveMember>
<gml:curveMember>
<gml:Curve gml:id="_6">
<gml:segments>
<gml:LineStringSegment>
<gml:posList>601078.954 5943996.138</gml:posList>
<gml:posList>601085.954 5943996.138</gml:posList>
</gml:LineStringSegment>
</gml:segments>
</gml:Curve>
</gml:curveMember>
</gml:Ring>
</gml:exterior>
</gml:PolygonPatch>
</gml:patches>
</gml:Surface>
</position>
<!-- ... -->
</AX_Flurstueck>
<!-- ... -->
<AX_Gebaeude gml:id="DEBY000000000002">
<!-- ... -->
<position>
<gml:Surface srsName="urn:adv:crs:DE_DHDN_3GK3" gml:id="_7">
<gml:patches>
<gml:PolygonPatch>
<gml:exterior>
<gml:Ring gml:id="_8">
<gml:curveMember>
<gml:Curve gml:id="_9">
<gml:segments>
<gml:LineStringSegment>
<gml:posList>601082.954 5943994.138</gml:posList>
<gml:posList>601082.954 5943996.138</gml:posList>
</gml:LineStringSegment>
</gml:segments>
</gml:Curve>
</gml:curveMember>
<gml:curveMember>
<gml:Curve gml:id="_10">
<gml:segments>
<gml:LineStringSegment>
<gml:posList>601082.954 5943996.138</gml:posList>
<gml:posList>601078.954 5943996.138</gml:posList>
</gml:LineStringSegment>
</gml:segments>
</gml:Curve>
</gml:curveMember>
<gml:curveMember>
<gml:Curve gml:id="_11">
<gml:segments>
<gml:LineStringSegment>
<gml:posList>601078.954 5943996.138</gml:posList>
<gml:posList>601078.954 5943994.138</gml:posList>
</gml:LineStringSegment>
</gml:segments>
</gml:Curve>
</gml:curveMember>
<gml:curveMember>
<gml:Curve gml:id="_12">
<gml:segments>
<gml:LineStringSegment>
<gml:posList>601078.954 5943994.138</gml:posList>
<gml:posList>601082.954 5943994.138</gml:posList>
</gml:LineStringSegment>
</gml:segments>
</gml:Curve>
</gml:curveMember>
</gml:Ring>
</gml:exterior>
</gml:PolygonPatch>
</gml:patches>
</gml:Surface>
</position>
<!-- ... -->
</AX_Gebaeude>
<!-- ... -->
Und zum Vergleich die rechte Situation, bei der die untere Kante des Flurstücks zur Herstellung der Geometrieidentität im oben beschriebenen Sinne in zwei Kanten in der Erhebungskomponente aufgetrennt wurde:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
<!-- ... -->
<AX_Flurstueck gml:id="DEBY000000000001">
<!-- ... -->
<position>
<gml:Surface srsName="urn:adv:crs:DE_DHDN_3GK3" gml:id="_1">
<gml:patches>
<gml:PolygonPatch>
<gml:exterior>
<gml:Ring gml:id="_2">
<gml:curveMember>
<gml:Curve gml:id="_3">
<gml:segments>
<gml:LineStringSegment>
<gml:posList>601085.954 5943996.138</gml:posList>
<gml:posList>601085.954 5943998.138</gml:posList>
</gml:LineStringSegment>
</gml:segments>
</gml:Curve>
</gml:curveMember>
<gml:curveMember>
<gml:Curve gml:id="_4">
<gml:segments>
<gml:LineStringSegment>
<gml:posList>601085.954 5943998.138</gml:posList>
<gml:posList>601078.954 5943998.138</gml:posList>
</gml:LineStringSegment>
</gml:segments>
</gml:Curve>
</gml:curveMember>
<gml:curveMember>
<gml:Curve gml:id="_5">
<gml:segments>
<gml:LineStringSegment>
<gml:posList>601078.954 5943998.138</gml:posList>
<gml:posList>601078.954 5943996.138</gml:posList>
</gml:LineStringSegment>
</gml:segments>
</gml:Curve>
</gml:curveMember>
<gml:curveMember>
<gml:Curve gml:id="_6">
<gml:segments>
<gml:LineStringSegment>
<gml:posList>601078.954 5943996.138</gml:posList>
<gml:posList>601082.954 5943996.138</gml:posList>
</gml:LineStringSegment>
</gml:segments>
</gml:Curve>
</gml:curveMember>
<gml:curveMember>
<gml:Curve gml:id="_7">
<gml:segments>
<gml:LineStringSegment>
<gml:posList>601082.954 5943996.138</gml:posList>
<gml:posList>601085.954 5943996.138</gml:posList>
</gml:LineStringSegment>
</gml:segments>
</gml:Curve>
</gml:curveMember>
</gml:Ring>
</gml:exterior>
</gml:PolygonPatch>
</gml:patches>
</gml:Surface>
</position>
<!-- ... -->
</AX_Flurstueck>
<!-- ... -->
<AX_Gebaeude gml:id="DEBY000000000002">
<!-- ... -->
<position>
<gml:Surface srsName="urn:adv:crs:DE_DHDN_3GK3" gml:id="_8">
<gml:patches>
<gml:PolygonPatch>
<gml:exterior>
<gml:Ring gml:id="_9">
<gml:curveMember>
<gml:Curve gml:id="_10">
<gml:segments>
<gml:LineStringSegment>
<gml:posList>601082.954 5943994.138</gml:posList>
<gml:posList>601082.954 5943996.138</gml:posList>
</gml:LineStringSegment>
</gml:segments>
</gml:Curve>
</gml:curveMember>
<gml:curveMember>
<gml:Curve gml:id="_11">
<gml:segments>
<gml:LineStringSegment>
<gml:posList>601082.954 5943996.138</gml:posList>
<gml:posList>601078.954 5943996.138</gml:posList>
</gml:LineStringSegment>
</gml:segments>
</gml:Curve>
</gml:curveMember>
<gml:curveMember>
<gml:Curve gml:id="_12">
<gml:segments>
<gml:LineStringSegment>
<gml:posList>601078.954 5943996.138</gml:posList>
<gml:posList>601078.954 5943994.138</gml:posList>
</gml:LineStringSegment>
</gml:segments>
</gml:Curve>
</gml:curveMember>
<gml:curveMember>
<gml:Curve gml:id="_13">
<gml:segments>
<gml:LineStringSegment>
<gml:posList>601078.954 5943994.138</gml:posList>
<gml:posList>601082.954 5943994.138</gml:posList>
</gml:LineStringSegment>
</gml:segments>
</gml:Curve>
</gml:curveMember>
</gml:Ring>
</gml:exterior>
</gml:PolygonPatch>
</gml:patches>
</gml:Surface>
</position>
<!-- ... -->
</AX_Gebaeude>
<!-- ... -->
Die Themen werden in der NAS-Datei wie folgt abgebildet:
-
Die Themen, und dies gilt sowohl für "TS_Theme" als auch das "PunktLinienThema", sind (implizite) Realisierungen von GM_Complex und sind letztlich eine Aggregation von geometrischen Elementen. Sie können im AFIS-ALKIS-ATKIS-Kontext nur in einer vollständigen Form (Art der Themendeklaration = "alle Objekte", Klassenthemen) vorkommen.
-
Bei der vollständigen, klassenbezogenen Form liegen alle Objekte einer Objekt-art automatisch in diesem Thema. Es besteht keine "Wahlmöglichkeit".
Die bis zur GeoInfoDok Version 6.0.1 mögliche, instanzenbezogene Angabe der geometrischen Identität ist nicht mehr vorgesehen, da eine eindeutige Zuordnung zwischen einer geometrischen Identität und dem entsprechenden Thema nicht möglich war, sondern nur allgemeingültig für alle Instanzen in den Produkt-Metadaten angegeben werden konnte. Zudem waren keine fachlichen Anforderungen zur Erfassung und Führung dieser Funktionalität bekannt.
Codierung von Verweisen auf Koordinatenreferenzsysteme in der NAS
Grundsätzlich muss jede Geometrieeinheit in der NAS-Datei (Punkt, Linie, Fläche) auf ein Koordinatenreferenzsystem (CRS) verweisen. Dies kann entweder implizit durch Angabe des CRS bei einer übergeordneten Geometrieeinheit oder explizit bei der jeweiligen Geometrieeinheit erfolgen. Der Verweis erfolgt durch Angabe eines URI (Uniform Resource Identifier). Um diese Angabe nicht immer bei jeder Objektgeometrie machen zu müssen, werden in den Exchange Metadata der NAS alle verwendeten Referenzsysteme angegeben, von denen eines als Standardreferenzsystem gekennzeichnet werden kann. Für Geometrien, die in diesem Standardreferenzsystem vorliegen, muss keine Angabe zum Koordinatenreferenzsystem mehr gemacht werden. Das dafür vorgesehene Attribut bei GML-Geometrien "srsName" ist in diesen Fällen nicht vorhanden. Für alle Geometrien, die nicht im Standardreferenzsystem vorliegen, ist das Attribut zu belegen. Hierbei sind die in Abschnitt 8.1 beschriebene Syntax und die dort definierten Bezeichnungen zu verwenden.
Bei NAS-Dokumenten, die Objekte in einer "FeatureCollection" enthalten, ist das Standardreferenzsystem im Attribut "srsName" des "gml:Envelope" anzugeben.
Darüber hinaus dient die Deklaration der verwendeten Koordinatenreferenzsysteme in den Exchange Metadata der Angabe der für das Referenzsystem geltenden Koordinatenauflösung bzw. der Anzahl der relevanten Nachkommastellen. Diese kann von Referenzsystem zu Referenzsystem unterschiedlich sein und macht keine Aussage über die Genauigkeit der Koordinaten. In AFIS-ALKIS-ATKIS ist die Koordinatenauflösung für metrische Lagekoordinaten auf 3 Nachkommastellen (mm) festgelegt. Die Angabe der relevanten Nachkommastellen ist notwendig, da sowohl GML als auch ISO 19107 Spatial Schema keine Einschränkungen diesbezüglich machen und auch keine Möglichkeiten dazu vorsehen (Datentyp: decimal oder double). Folgende Definition wird in den NAS Schema-Dateien verwendet:
1
2
3
4
5
6
7
<xs:complexType name="AA_Koordinatenreferenzsystemangaben">
<xs:sequence>
<xs:element name="crs" type="gml:CRSPropertyType"/>
<xs:element name="anzahlDerNachkommastellen" type="xs:integer"/>
<xs:element name="standard" type="xs:boolean"/>
</xs:sequence>
</xs:complexType>
Codierung von Verweisen auf Maßeinheiten in der NAS
Grundsätzlich muss jeder mit einer Maßeinheit versehene Wert in der NAS-Datei (z.B. Längen, Flächen, Winkel) auf eine Maßeinheit verweisen. Der Verweis erfolgt durch Angabe eines URI (Uniform Resource Identifier) im Attribut "uom". Hierbei sind die in Abschnitt 8.2 beschriebene Syntax und die dort definierten Bezeichnungen zu verwenden.
Codierung von Verweisen auf Werte aus Codelisten
Jedes Attribut mit einem Wert aus einer Codelist wird in der NAS als Verweis auf einen Codelistenwert in einer Registry für Codelisten (siehe Abschnitt 7.2) codiert. Der Verweis wird als HTTP URI in einem xlink:href-Attribut codiert. Hierbei ist der Text des Wertes im Attribut xlink:title aufzunehmen.
Beispiel:
<AX_Flurstueck gml:id="DEBBxxxxxxxxxxxx">
<!-- ... -->
<anlass xlink:title="Ersteinrichtung" xlink:href="https://registry.gdi-de.org/codelist/de.adv-online.gid/AA_Anlassart/000000"/>
<!-- ... -->
</AX_Flurstueck>
Codierung von Zeilenumbrüchen in Schriftinhalten von Präsentationsobjekten
Für eine korrekte Darstellung von Schriftinhalten wird gelegentlich ein Zeilenumbruch nötig. Dieser muss im Schriftinhalt eines Präsentationsobjektes durch ein entsrechendes LF-Zeichen "\n" angegeben werden. In XML wird ein LF durch ein Zeichen - typischerweise #xA - repräsentiert.
4.5. GML-Profil für die NAS
Als Bestandteil der NAS wird ein GML-Profil dokumentiert, das die GML-Elemente und -Typen auf den benötigten Umfang eingrenzt und in der aktuellen Version nicht benötigte Teile, wie die Topologie oder nicht unterstützte Objekteigenschaften, "ausblendet".
Neben der Weglassung von fachlich nicht benötigten GML-Strukturen wurde auch eine Reihe von zusätzlichen Festlegungen zur Verwendung von GML in der NAS getroffen. Ziel ist die Beschränkung von Freiräumen der Codierung, sodass die Verarbeitung von NAS-Dokumenten erleichtert wird:
-
Bei GML-Objekten, die neben der Verwendung von normalen auch Array-Eigenschaften erlauben, wurde eine der Varianten, i.d.R. die Array-Eigenschaften, gestrichen.
-
Bei der Darstellung von GM_PolyhedralSurface in den Daten wird die Verwendung von gml:Surface mit genau einem gml:PolygonPatch vorgeschrieben. (gml:Polygon darf in diesen Fällen nicht verwendet werden und ist ausschließlich in Filterausdrücken erlaubt.)
-
Da die Mehrzahl der unter Verwendung von GM_MultiSurface definierten Flächenobjekte (z.B. Flurstücke) aus lediglich einer einzigen Fläche bestehen, wird vorgeschrieben, dass bei einer einzigen Fläche stets gml:AbstractSurface zu verwenden ist und die Verwendung von gml:MultiSurface nur bei mehreren getrennten Flächen erlaubt ist.
-
Bei der Darstellung von GM_Ring in den Daten wird die Verwendung von gml:Ring mit gml:Curve vorgeschrieben (gml:LinearRing darf in diesen Fällen nicht verwendet werden und ist ausschließlich in Filterausdrücken erlaubt).
-
Für Koordinatenangaben muss gml:pos (bei gml:Point) bzw. gml:posList (bei anderen Geometrieobjekten) verwendet werden.
-
Die Standardeigenschaften von GML-Objekten "gml:name" und "gml:description" dürfen nur in GML-Dictionaries verwendet werden, nicht in Eigenschaften von Objekten im Namespace der NAS.
-
Bei GMD-Objekten ist bei der Abbildung der DQ-Element in der NAS als gmd:LI_Lineage-Elemente folgendes zu beachten:
-
Es darf nur das Element gmd:processStep enthalten sein
-
Das Element muss mindestens einmal vorkommen
-
Das Element darf maximal so oft vorkommen, wie im konzeptuellen Modell beschrieben (d.h. in der Regel einmal, bis auf in AX_DQPunktort, dort zweimal).
-
Es ist zu beachten, dass die Schemadatei des Profils (gmlProfileNAS.xsd) standardmäßig nicht zum Validieren verwendet wird (aufgrund der Regeln, wie in XML Schema die schemaLocation-Attribute interpretiert werden). Um Fehlinterpretationen auszuschließen wurde auch der Namespace der Schemadatei des GML-Profils auf einen anderen Namespace als den von XML Schema geändert. Sofern lokal die Schemadatei zu Validierungszwecken verwendet werden soll, ist der Dateiinhalt entsprechend anzupassen.
5. NAS-Operationen
Die NAS ist vom Grundsatz her zunächst für die Kommunikation nach "außen", d.h. für die Nutzer der AAA-Daten konzipiert. Darüber hinaus kann sie, je nach Implementierungskonzept, auch für die interne Kommunikation zwischen Erfassungs- bzw. Qualifizierungssystemen und Führungssystemen verwendet werden. In den folgenden Kapiteln sind die letztgenannten Funktionalitäten mit berücksichtigt. Eine Implementierung, die die interne Kommunikation mit systemspezifischen Funktionen ermöglicht, muss aus der Palette der beschriebenen Operationen der NAS nur diejenigen bereitstellen, die für die Abgabe von Daten an Dritte relevant sind. Dazu gehören insbesondere die Abgabe von Benutzungsdaten und die Führung von Sekundärnachweisen. Im Zuge der Realisierung einer netzbasierten Geodateninfrastruktur kann es darüber hinaus notwendig werden, weitere Funktionen als NAS-Operationen zur Verfügung zu stellen.
Eine einheitliche und standardisierte Festlegung zur Datenübermittlung zwischen den Systemen verschiedener AAA-Softwareanbieter ist länderspezifisch zu realisieren. Aufgrund der unterschiedlichen Länderlösungen ist eine einheitliche Regelung in der GeoInfoDok zur automatisierten Kommunikation zwischen Primär- und Sekundärdatenhaltung nicht möglich.
Für die Verwendung in Fachinformationssystemen sind drei allgemeine Operationen zur Fortführung von Bestandsdaten, zur Abfrage von Auszügen aus den Bestandsdaten und zur generellen Auskunft über die Eigenschaften der Bestandsdatenhaltung spezifiziert.
5.1. Funktionsumfang
Die NAS soll verschiedene Operationen unterstützen. Folgender Bedarf wird z.Zt. gesehen:
-
Einrichten und Fortführen von Primärnachweisen
-
Anfordern von Ausgaben
-
Ausgabe von Benutzungsdaten (Auszüge)
-
Führen von Sekundärnachweisen (Erstausstattung und Fortführung)
-
-
Sperren und Entsperren von Objekten
-
Reservieren (von Punktnummer u.a.)
-
Übermittlung von Protokollinformationen (z.B. Verarbeitungsprotokolle, Fehlerprotokolle)
-
Ermitteln der Eigenschaften einer Bestandsdatenhaltung
Zu jeder NAS-Operation gehören zwei XML-Schema-Definitionen, eine für den Aufruf der Operation (Request) und eine für das Ergebnis (Response):
-
Aufruf (Request)
z.B. Fortführungsauftrag, Benutzungsauftrag -
Ergebnis (Response)
z.B. Fortführungsprotokoll, Benutzungsergebnis
Hierbei ist durchaus die Mehrfachverwendung einer XML-Schema-Definition für mehrere Operationen möglich. Soweit standardisierte XML-Schemata für die genannten Zwecke vorliegen, werden diese verwendet, im anderen Fall werden die Definitionen selbst erstellt. Die XML-Schema-Definitionen für NAS-Operationen werden, wie alle anderen Inhalte der NAS, automatisch aus UML-Modellen abgeleitet werden. Für die Anwendungsbereiche AFIS und ALKIS wurden die UML-Modelle dazu bereits erstellt. Sollte es sich herausstellen, dass die dort vorgenommenen Definitionen auch für andere Anwendungen verwendet werden sollen, so sind jene an dieser Stelle aufzunehmen.
Alle XML-Schemata für die NAS-Operationen sind in der Datei NAS-Operationen.xsd zusammengefasst. Die allgemein verwendbaren Basisoperationen sind in der Datei AAA-Bassisschema.xsd enthalten.
Den Operationen liegt die OGC Web Services Common Specification 1.1 zugrunde, die einzuhalten ist. Insbesondere sollte jede NAS-Implementierung die GetCapabilities-Operation zu unterstützen.
5.1.1. Einrichten und Fortführen von Primärnachweisen
Da GML selbst keine Elemente für Fortführungsoperationen anbietet, werden zu diesem Zweck die Festlegungen des Web Feature Service (WFS) von OGC verwendet. In der WFS-Spezifikation sind neben dem Transaktionsmechanismus 4 Änderungsfunktionen definiert: <Insert> (neues Objekt einfügen), <Update> (Objekt ändern), <Replace> (Objekt überschreiben) und <Delete> (Objekt löschen). In der NAS wird bei der Fortführung von Primärnachweisen <Update> nicht verwendet. Welche Änderungen zu <Replace> oder zu <Delete> mit anschließendem <Insert> führen, ist in den Objektartenkatalogen fachlich festzulegen. Dies gilt sowohl für Änderungen in den Attributwerten und Relationen als auch für geometrische Änderungen. Bei letzteren muss ggf. der Bearbeiter im Erhebungsprozess entscheiden, welche Fortführungsart zu verwenden ist.
Beispiel:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
<wfs:Transaction>
<wfs:Insert>
<AX_Flurstueck gml:id="DEBY0000F0000001">
<!-- ... -->
</AX_Flurstueck>
<AX_Gebaeude gml:id="DEBY0000G0000001">
<!-- ... -->
</AX_Gebaeude>
</wfs:Insert>
<wfs:Replace>
<AX_Flurstueck gml:id="DEBY0000F0000002">
<!-- ... -->
</AX_Flurstueck>
<fes:Filter>
<fes:ResourceId rid="DEBY0000F000000220010101T000000Z"/>
</fes:Filter>
</wfs:Replace>
<wfs:Delete typeName=AX_Buchungsstelle">
<fes:Filter>
<fes:ResourceId rid="DEBY0000B000000320010101T000000Z"/>
<fes:ResourceId rid="DEBY0000B000000420010101T000000Z"/>
</fes:Filter>
</wfs:Delete>
</wfs:Transaction>
Folgendes ist zu beachten:
-
Die Filter-Ausdrücke bei <Delete>- und <Replace>-Operationen dürfen nur ResourceId-Elemente beinhalten. Komplexere Filterkriterien sind nicht erlaubt.
-
Bei ResourceId-Bedingungen in "<Replace>"- und "<Delete>"-Operationen wird der Identifikator zusätzlich um Entstehungsdatum/-zeit ergänzt, damit eine Prüfung auf Aktualität erfolgen kann. Datum und Uhrzeit werden ohne Trennzeichen kodiert, damit sie den Bedingungen einer XML ID genügen, also in der folgenden Form: CCYYMMDDThhmmssZ. Bezüglich der Ergänzung um Entstehungsdatum/-zeit gilt folgende Ausnahme: Innerhalb von Fortführungsaufträgen mit mehreren Fortführungsfällen kann bei <Replace> bzw. <Delete>-Anweisungen von mehrfach fortzuführenden Objekten ab dem 2. Fortführungsfall die Angabe von Entstehungsdatum/-zeit innerhalb der OID entfallen. Nur in diesem speziellen Fall erfolgt keine Prüfung der Aktualität und es wird die - soeben erzeugte - aktuelle Version genutzt.
-
In <Delete>-Operationen dürfen nur mehrere AAA-Objekte behandelt werden, wenn sie dieselbe Objektart haben; innerhalb von <Insert>-Operationen können unterschiedliche Objektarten vorkommen. <Replace>-Operationen behandeln immer nur ein Objekt.
-
Bei <Replace>-Operationen sind stets alle Eigenschaften des AAA-Objekts als "Properties" zu übergeben, also auch die unveränderten. Dies stellt eine Verschärfung der WFS-Spezifikation von OGC für die <Update>-Operation dar, in der gefordert wird, dass mindestens alle geänderten Eigenschaften übermittelt werden. Grund für diese Verschärfung war die Forderung, dass Datenhaltungskomponenten sich nicht merken müssen, welche Eigenschaften eines Objekts geändert wurden, sondern lediglich die Tatsache, dass ein Objekt geändert wurde.
-
In Analogie zu den ResourceId-Bedingungen müssen die OID bei Vorkommen mehrerer Versionen eines Objekts beim Objekt eindeutig sein. Dies wird durch Ergänzung der OID beim Objekt um Entstehungsdatum/-zeit ohne Trennzeichen erreicht.
-
Alle durchgeführten Änderungen innerhalb eines Fortführungsfalls werden zeitgleich gültig. In das Attribut "lebenszeitintervall" der Objekte wird die Systemzeit (umgerechnet in UTC) zum Beginn der Transaktion eingetragen. Dabei ist fallweise der Beginn- oder Endezeitpunkt zu belegen. Die angelieferten Angaben bei den einzelnen Fachobjekten sind unerheblich und werden überschrieben. Letzeres gilt nicht für die Ersteinrichtung eines Datenbestandes durch Übernahme von Objekten aus einem Vorgängerdatenbestand (Einrichtungsauftrag). Um hierbei ein Eintragen von historischen Informationen zu ermöglichen, wird dort die angelieferte Zeit übernommen. Wird als Datum/Zeit "9999-01-01T00:00:00Z" (Dummy-Datum/Zeit) angeliefert, so wird dies wie bei Fortführungsaufträgen mit der Systemzeit überschrieben. Zeitangaben werden immer in UTC-Zeit (Universal Time Coordinated, Greenwich Mean Time) gemacht. Die Zeiteinheit für die Einträge ins Lebenszeitintervall (Datentyp: DateTime) ist die volle Sekunde einschließlich der obligatorischen Kennung "Z" für UTC (CCYY-MM-DDTHH:MM:SSZ). Das Führungssystem stellt bei der Übernahme sicher, dass nicht 2 Versionen desselben Objekts mit identischem Lebenszeitintervall entstehen. Dies kann dann auftreten, wenn ein Objekt innerhalb eines Fortführungsauftrags in mehreren Fortführungsfällen verändert wird und diese aufgrund der Systemgeschwindigkeit in der gleichen Sekunde abgearbeitet werden.
-
Auf Objektarten, die den Stereotyp und den Tagged Value "retired" tragen, dürfen lediglich <Insert>- und <Delete>-Operationen angewendet werden, da im Rahmen der Einführung von neuen Referenzversionen der GeoInfoDok deren Migration und insgesamt auch deren Löschung vorgesehen sind. Fortführungen dieser Objekte in Primärnachweisen sind nicht erlaubt.
-
Attribute, Relationen und Wertearten mit dem Stereotyp und den Tagged Value "retired" dürfen keine Modifikationen erfahren. <Replace>-Operationen, welche die vorgenannten Dinge verändernd betreffen, sind daher unzulässig.
Die XML-Schemata für einen Fortführungsauftrag und sein Ergebnis sind wie alle anderen NAS-Operationen in der Datei NAS-Operationen.xsd enthalten. Einrichtungsaufträge und deren Ergebnisse sind Unterklassen von Fortführungsaufträgen.
Die Funktionen zur Fortführung werden in Systemen mit vollständigem Nachweis der Historie und in Systemen ohne vollständige Historie unterschiedlich ausgeführt:
Systeme ohne vollständigen Historiennachweis
<Insert>:
Die übermittelten Fachobjekte werden als neue Informationen eingetragen.
<Replace>:
Die übermittelten Fachobjekte ersetzen die Fachobjekte, die denselben Identifikator haben. Zur eindeutigen Bezeichnung der zu überschreibenden bzw. zu versionierenden Version wird der Identifikator (XML-Attribut rid) des neuen Fachobjekts im Filterausdruck um die Angabe des Entstehungsdatums/-zeit der zu überschreibenden Objektversion ergänzt. Damit sollen Fehler aufgedeckt werden, die durch Fortführungsaufträge entstehen könnten, die nicht zum gespeicherten Datenbestand passen. Im aufnehmenden System wird das Fachobjekt wieder mit dem originalen (nicht um Entstehungsdatum/-zeit ergänzten) Identifikator gespeichert. Es ist nicht zulässig, die Operation <Replace> durch <Delete> und nachfolgendes <Insert> mit demselben Identifikator zu ersetzen.
<Delete>:
Das Attribut rid des Filterausdrucks im WFS-<Delete>-Element bezeichnet das zu löschende Fachobjekt. Zur eindeutigen Bezeichnung der zu löschenden Version wird der Identifikator in der Austauschdatei um die Angabe des Entstehungsdatums/-zeit der zu löschenden Version ergänzt. Damit sollen Fehler aufgedeckt werden, die durch Fortführungsaufträge entstehen könnten, die nicht zum gespeicherten Datenbestand passen. Das so bezeichnete Objekt wird im aufnehmenden System mit allen selbstbezogenen Eigenschaften und referenzierten Raumbezugsgrundformen gelöscht. Raumbezugsgrundformen werden nur dann gelöscht, wenn sie von keinem weiteren Objekt referenziert werden.
Diese Funktionalität wird vor allem von Datenhaltungssystemen genutzt, die Sekundärdatenbestände halten.
Systeme mit vollständigem Historiennachweis
Ist das aufnehmende System zur Führung eines vollständigen Historiennachweises konfiguriert, reagiert es auf
<Insert>
mit der Erzeugung einer neuen Instanz eines Objektbehälters und fügt in den Behälter eine erste Version des übermittelten Fachobjekts ein.
<Replace>
Die übermittelten Fachobjekte werden als neue Version in den durch den Identifikator bezeichneten Objektbehälter eingetragen. Zur eindeutigen Bezeichnung der Vorgängerversion wird der Identifikator im Filterausdruck (XML-Attribut rid) des neuen Fachobjekts in der Austauschdatei um die Angabe des Entstehungsdatums/-zeit der zu überschreibenden Objektversion ergänzt. Damit sollen Fehler aufgedeckt werden, die durch Fortführungsaufträge entstehen könnten, die nicht zum gespeicherten Datenbestand passen. Im aufnehmenden System bleibt das überschriebene Fachobjekt als historische Version bestehen.
<Delete>
Die im Filterausdruck durch den um Entstehungsdatum/-zeit erweiterten Identifikator (XML-Attribut rid) bezeichnete Version des Fachobjekts wird mit dem aktuellen Untergangsdatum/-zeit (aus der Systemzeit abgeleitet) versehen und dadurch historisiert. Das System stellt sicher, dass keine weiteren Versionen angelegt werden können.
Diese Funktionalität wird auch von den Datenhaltungssystemen genutzt, die die Versionierung nur befristet zur Bereitstellung von Fortführungsinformationen für Dritte im Rahmen des NBA-Verfahrens (s.u.) verwenden.
Das konzeptuelle Fachmodell für die Fortführung von ALKIS sowie die Abläufe bei dessen Fortführungsverarbeitung sind im Abschnitt "Erläuterungen zu ALKIS" TBD: Genaue Referenz? beschrieben.
Hinweis: Das Fortführungsergebnis liefert derzeit nur minimale Informationen zurück. Grundsätzlich sinnvoll wären eine Gegenüberstellung von temporären und endgültigen Identifikatoren sowie eine Rückgabe von Entstehungsdatum/-zeit pro Fortführungsfall. Da dies in der aktuellen Version nicht erfolgt, müssen diese Informationen bei Bedarf, z.B. zur Codierung von Folgefortführungen, über einen nachfolgenden Bestandsdatenauszug aus der DHK erfragt werden.
5.1.2. Anfordern von Ausgaben
Die aus einem Datenhaltungssystem auszugebenden Daten (Benutzungsdaten oder Daten zur Führung von Sekundärnachweisen) werden hinsichtlich des auszugebenden Informationsumfangs durch Kriterien zur Selektion und Filterung bestimmt. Ein Datenhaltungssystem muss deshalb in der Lage sein, komplexe Selektions- und Filterausdrücke auszuwerten und die sich damit qualifizierenden Daten auszugeben. Die Selektion erfolgt durch räumliche, fachliche (Objektart, Attribut, Relation) und zeitliche Kriterien. Diese Kriterien können auch geschachtelt und miteinander verbunden werden, so dass ganze Selektionsketten entstehen. Damit kann auch formuliert werden, welche Elemente weitere Elemente über Referenzen zur Ausgabe nachziehen. In der NAS wird stets nur die im Anwendungsschema als navigierbare Richtung gekennzeichnete Rolle der Assoziation angegeben. Gegenrelationen sind in der NAS nicht zulässig. Gleichwohl ist es zur Vereinfachung von Filterausdrücken möglich, Objekte anzufordern, die per Gegenrelation mit einem Objekt verbunden sind. Hierbei ist - soweit vorhanden - der explizit im Modell benannte Rollenname der Gegenrelation zu verwenden, in Ermangelung eines solchen der um "inversZu_" ergänzte Rollenname der als navigierbare Richtung gekennzeichneten Rolle.
Kriterien der Filterung bestimmen, welche Elemente der Selektionskette ausgegeben werden sollen und welche Attribute und Verweise mit diesen Elementen ausgegeben werden.
Die Selektions- und Filterungskriterien werden als Bestandteil der Benutzungsanforderung an das datenführende System übermittelt oder dort in Benutzerprofilen hinterlegt. Für die Definition einheitlicher Produkte der AdV werden einheitliche Selektions- und Filterkriterien definiert. Als formale Sprache zur Definition der Selektionsketten wird die Filter Encoding Specification von OGC verwendet.
Das XML-Schema für einen Benutzungsauftrag ist in der Datei NAS-Operationen.xsd enthalten. Es nutzt das Schema filter.xsd von OGC.
Grundsätze für die Selektion von Objekten (Filter Encoding)
Zum Codieren einer Selektion wird das <wfs:Query>-Element aus der "Web Feature Service"-Spezifikation (WFS) des Open Geospatial Consortiums in der Version 2.0 verwendet. In einer Selektion können mehrere Queries vorkommen, wobei sich jede Query auf eine instanziierbare Objektart bezieht. Die unterschiedlichen Queries wirken ergänzend.
Die aktuelle Filter-Encoding-Spezifikation unterstützt bei Ad-Hoc-Queries und den geforderten Konformitätsklassen nur die Angabe der konkreten, instanziierten Objektarten, d.h. die im AAA-Anwendungsschema modellierte Vererbungshierarchie wird nicht unterstützt. Es ist also z.B. nicht möglich, eine einzige Query für "AX_TatsaechlicheNutzung" abzusetzen, um alle TN-Objekte zu erfragen, sondern es muss ein <wfs:Query>-Element pro Objektart angegeben werden. Hierfür wäre eine Unterstützung der Konformitätsklasse "Schema Element Function" erforderlich. Queries auf Modellelemente mit Stereotype und Tagged Value "retired" sind ohne Einschränkungen möglich.
In eine <wfs:Query> eingebettet ist u.a. ein <fes:Filter>-Element zur Filterung der Objekte aus dem Gesamtumfang der Objektart. Ein <fes:Filter>-Ausdruck besteht aus einem Prädikat, das für jedes Objekt der Objektart in der Datenbasis, auf der die Suche ausgeführt werden soll, angewendet wird. Erfüllt das Objekt das Prädikat, ist es Teil der Selektion, ansonsten nicht. Die Prädikate sind entsprechend so zu verstehen, dass sie grundsätzlich auf den XML-Instanzen wirken, die diese Objekte repräsentieren.
Entsprechend besteht das Prädikat aus einem booleschen Ausdruck, der aus beliebig vielen atomaren Operatoren besteht, die über
-
die logischen Operatoren
<fes:And>
<fes:Or>
<fes:Not>
verbunden werden.
Bei den atomaren Operatoren werden
-
räumliche Operatoren
<fes:Equals>
<fes:Disjoint>
<fes:Touches>
<fes:Within>
<fes:Overlaps>
<fes:Crosses>
<fes:Intersects>
<fes:Contains>
<fes:DWithin>
<fes:Beyond>
<fes:BBOX>
und
-
Vergleichsoperatoren
<fes:PropertyIsEqualTo> (=)
<fes:PropertyIsNotEqualTo> (<>)
<fes:PropertyIsLessThan> (<)
<fes:PropertyIsGreaterThan> (>)
<fes:PropertyIsLessThanOrEqualTo> (=<)
<fes:PropertyIsGreaterThanOrEqualTo> (>=)
<fes:PropertyIsLike> (Textvergleich mit Wildcards für ein oder mehrere Zeichen)
<fes:PropertyIsNull> (Prüfung auf fehlenden Wert)
<fes:PropertyIsBetween> (Kombination von >= und <=)
unterstützt. Die Bedeutung der logischen Operatoren und der Vergleichsoperatoren ergibt sich aus der in SQL verwendeten bzw. der direkt mit dem Namen ausgedrückten Bedeutung.
Die Bedeutung der räumlichen Operatoren ist i.d.R. in der OpenGIS Simple Features Spezifikation definiert und in das Filter Encoding übernommen worden. Vermutlich ist <fes:Intersects> der wichtigste Operator, der "true" ergibt, wenn zwei Geometrien nicht überschneidungsfrei sind. <fes:BBOX> ist eine vereinfachte Form, die als Testgeometrie nur eine Bounding Box erlaubt. <fes:Disjoint> ist die Umkehrung zu <fes:Intersects>. <fes:Contains> oder <fes:Within> sind zu verwenden, wenn es nicht um Überlappung geht, sondern um echtes Enthaltensein. Für weitergehende Fragen, siehe die OpenGIS Spezifikationen Filter Encoding und Simple Features for SQL.
Bei räumlichen Operatoren und den Vergleichsoperatoren wird i.d.R. eine Eigenschaft des Objekts angegeben, für die der Vergleich durchgeführt werden soll.
Dies geschieht unter Verwendung von Xpath, dabei beschränkt man sich auf die Kurzschreibweise. Dies bedeutet:
-
Ein Attribut att der Query-Objektart wird wie folgt referenziert:
<fes:ValueReference>att</fes:ValueReference>Oder mit einem konkreten Beispiel aus dem AAA-Anwendungsschema:
<fes:ValueReference>flurstueckskennzeichen</fes:ValueReference> -
Sofern att ein Attribut der Query-Objektart ist und der Wert des Attributs vom Datentyp AX_DT ist und darin das Attribut att2 referenziert werden soll, dann geschieht dies wie folgt:
<fes:ValueReference>att/AX_DT/att2</fes:ValueReference>Oder mit einem konkreten Beispiel aus dem AAA-Anwendungsschema:
<fes:ValueReference>lebenszeitintervall/AA_Lebenszeitintervall/endet</fes:ValueReference> -
Eine Relation (genauer gesagt die Rolle in der Definitionsrichtung einer Relation) rel der Query-Objektart wird wie folgt referenziert:
<fes:ValueReference>rel</fes:ValueReference>Handelt es sich dabei um die Objektart AX_OA als Relationspartner und besitzt dieses ein Attribut att3, dann wird dieses wie folgt referenziert:
<fes:ValueReference>rel/AX_OA/att3</fes:ValueReference>Oder mit einem konkreten Beispiel aus dem AAA-Anwendungsschema (über zwei Relationen):
<fes:ValueReference>istGebucht/AX_Buchungsstelle/zu/AX_Buchungsstelle/laufendeNummer</fes:ValueReference>In Fällen wo ein Relationspartner im Schema eine abstrakte Objektart ist (z.B. AA_ZUSO), muss in dem Xpath-Ausdruck eine instanziierbare Objektart genannt werden, wie in dem folgenden Beispiel:
<fes:ValueReference>istTeilVon/AX_Schwerefestpunkt/bestehtAus/AX_Schwere/schweresystem</fes:ValueReference>In diesem Fall werden alle Eigenschaftspfade, die nicht dem Xpath-Ausdruck genügen, nicht beachtet. Ist das in der Selektion zu prüfende Objekt gleichzeitig Teil von einem Schwerefestpunkt und einem anderen ZUSO werden keine Eigenschaften des anderen ZUSO in der Selektion berücksichtigt; ebenso werden keine anderen Objekte, aus denen der Schwerefestpunkt neben AX_Schwere-Objekten besteht, berücksichtigt.
-
Für den Fall, dass ein XML-Attribut konkret referenziert und ausgewertet werden muss (z.B. "uom" oder "srsName"), so geschieht dies wie folgt:
<fes:ValueReference>att/@xmlatt</fes:ValueReference>Oder mit zwei konkreten Beispielen aus dem AAA-Anwendungsschema:
<fes:ValueReference>amtlicheFlaeche/@uom</fes:ValueReference><fes:ValueReference>bestehtAus/AX_PunktortAU/@srsName</fes:ValueReference>
Hierbei wird davon ausgegangen, dass der Default-Namespace des XML-Dokuments "http://www.adv-online.de/namespaces/adv/gid/version" ist. Ansonsten sind alle Bezeichner durch das Namespacekürzel zu qualifizieren (wie dies im Beispiel von xlink:href oben bereits erfolgt ist), also in der Regel
<fes:ValueReference>adv:att</fes:ValueReference>
statt
<fes:ValueReference>att</fes:ValueReference>
Im Fall von einfachen Attributen wird i.d.R. der Vergleichsoperator den Attributwert mit einem festen Wert vergleichen (Element <fes:Literal>), z.B.
<fes:PropertyIsEqualTo>
<fes:ValueReference>stellenart</fes:ValueReference>
<fes:Literal>1100</fes:Literal>
</fes:PropertyIsEqualTo>
was für alle Objekte in der Datenbasis erfüllt ist, bei denen das Stellenart-Attribut einen entsprechenden Wert (Werteart 1100) aufweist, oder
<fes:PropertyIsGreaterThanOrEqualTo>
<fes:ValueReference>lebenszeitintervall/AA_Lebenszeitintervall/beginnt</fes:ValueReference>
<fes:Literal>2003-05-20T00:00:00Z</fes:Literal>
</fes:PropertyIsGreaterThanOrEqualTo>
oder
<fes:PropertyIsLessThan>
<fes:ValueReference>lebenszeitintervall/AA_Lebenszeitintervall/endet</fes:ValueReference>
<fes:Literal>2003-05-20T00:00:00Z</fes:Literal>
</fes:PropertyIsGreaterThanOrEqualTo>
oder im Fall der Prüfung auf einen nicht vorhandenen Wert
<fes:PropertyIsNull>
<fes:ValueReference>lebenszeitintervall/AA_Lebenszeitintervall/endet</fes:ValueReference>
</fes:PropertyIsNull>
Für den Operator <PropertyIsNotEqualTo> des OGC-Filter Encodings gehören keine NULL-Werte zur Ergebnismenge. <PropertyIsNotEqualTo> liefert somit zu <PropertyIsEqualTo> keine komplementären Mengen zurück, sodass eine zusätzliche <PropertyIsNull>-Abfrage hinzugenommen werden muss.
Dies ist beispielsweise bei einer Abfrage nach allen Flustücksnennern ungleich 3 bezogen auf folgenden Gesamtbestand der Fall: Flurstück 100/1, 100/2, 100/3, 111. <PropertyIsNotEqualTo> 3 </PropertyIsNotEqualTo> würde liefern: Flurstücke 100/1, 100/2, nicht aber 111.
Für die Prüfung auf Werte in einem Bereich, z.B. für die Prüfung ob die Stellenart ein Wert im 1xxx-Bereich ist, würde folgender Vergleich verwendet:
<fes:PropertyIsBetween>
<fes:ValueReference>stellenart</fes:ValueReference>
<fes:LowerBoundary>
<fes:Literal>1000</fes:Literal>
</fes:LowerBoundary>
<fes:UpperBoundary>
<fes:Literal>1999</fes:Literal>
</fes:UpperBoundary>
</fes:PropertyIsBetween>
Analog ein Prädikat für Flurstücke mit einer amtlichen Fläche von mindestens 1000qm aber maximal 2000qm:
<fes:PropertyIsBetween>
<fes:ValueReference>amtlicheFlaeche</fes:ValueReference>
<fes:LowerBoundary>
<fes:Literal>1000</fes:Literal>
</fes:LowerBoundary>
<fes:UpperBoundary>
<fes:Literal>2000</fes:Literal>
</fes:UpperBoundary>
</fes:PropertyIsBetween>
Der LIKE-Vergleich ist für flexible Textvergleiche hilfreich. So filtert das folgende Prädikat alle Anschriften heraus, deren Telefonnummer mit 0228 beginnt
<fes:PropertyIsLike wildCard="*" singleChar="?" escapeChar="\">
<fes:ValueReference>telefon</fes:ValueReference>
<fes:Literal>0228*</fes:Literal>
</fes:PropertyIsLike>
während das folgende Prädikat die Personen filtert, bei denen der Geburtsname gesetzt ist, mit einem "M" beginnt und als dritten und vierten Buchstaben ein "t" hat:
<fes:PropertyIsLike wildCard="*" singleChar="?" escapeChar="\">
<fes:ValueReference>geburtsname</fes:ValueReference>
<fes:Literal>M?tt*</fes:Literal>
</fes:PropertyIsLike>
Bei räumlichen Operatoren erfolgt ein Vergleich einer Eigenschaft (der Name der geometrischen Attributart) mit einer festen Geometrie analog zu den Vergleichen einer textlichen oder numerischen Eigenschaft mit einem festen Wert. Bei den räumlichen Operatoren wird der feste Wert statt durch ein <fes:Literal>-Element durch das jeweilige GML-Geometrieelement ausgedrückt, zum Beispiel
<fes:Intersects>
<fes:ValueReference>position</fes:ValueReference>
<gml:Polygon gml:id="_1">
<gml:exterior>
<gml:Ring>
<!-- hier steht der Umring der Suchfläche -->
</gml:Ring>
</gml:exterior>
</gml:Polygon>
</fes:Intersects>
Sofern der Gesamtschlüssel eines Katalogeintrags bekannt ist, kann der entsprechende Katalogeintrag z.B. mit einer Query der folgenden Art erfragt werden (hier die Gemarkung mit der Kennung "071234"):
<wfs:Query typeNames="AX_Gemarkung">
<fes:Filter>
<fes:PropertyIsEqualTo>
<fes:ValueReference>schluesselGesamt</fes:ValueReference>
<fes:Literal>071234</fes:Literal>
</fes:PropertyIsEqualTo>
</fes:Filter>
</wfs:Query>
Sollen alle Katalogeinträge mit einem bestimmten Teilschlüssel erfragt werden, dann kann entweder mit <fes:PropertyIsLike> oder mit Vergleichsoperatoren für die einzelnen Attribute des Schlüssel-Datentyps gesucht werden. Alle Gemarkungen im Land findet man z.B. mit:
<wfs:Query typeNames="AX_Gemarkung">
<fes:Filter>
<fes:PropertyIsLike wildCard="*" singleChar="?" escapeChar="\">
<fes:ValueReference>schluesselGesamt</fes:ValueReference>
<fes:Literal>07*</fes:Literal>
</fes:PropertyIsLike>
</fes:Filter>
</wfs:Query>
oder
<wfs:Query typeNames="AX_Gemarkung">
<fes:Filter>
<fes:PropertyIsEqualTo>
<fes:ValueReference>schluessel/AX_Gemarkung_Schluessel/land</fes:ValueReference>
<fes:Literal>07</fes:Literal>
</fes:PropertyIsEqualTo>
</fes:Filter>
</wfs:Query>
Neben der Filter-Bedingung können in das <wfs:Query>-Element noch weitere Elemente eingebettet sein. Das Element <wfs:PropertyName> mit dem Attribut resolve="local" kann dazu genutzt werden, mit einer Query auf einen Schlag auch noch weitere Objekte in die Ergebnismenge aufzunehmen. Auf diese Weise kann die Anzahl der Queries - und damit auch der Benutzungsaufträge - häufig deutlich reduziert werden.
Das Element
<wfs:PropertyName resolve="local" resolveDepth="1">
gehoertAnteiligZu
</wfs:PropertyName>
in einer AX_Flurstueck-Query führt dazu, dass entlang der Relation gehoertAnteiligZu alle Relationspartner bis zu einer Tiefe von 1 (also die direkten Relationspartner, in diesem Fall die betroffenen Flurstücke) in die Ergebnismenge aufgenommen werden.
Ein anderes Beispiel, dass alle Punktorte mit unanhängiger Geometrie sowie alle ihre ZUSOs zurückliefert:
<wfs:Query typeNames="AX_Punktort_AU">
<wfs:PropertyName resolve="local" resolveDepth="1">istTeilVon</wfs:PropertyName>
</wfs:Query>
Eine weitere Präzisierung der Abfrage wird durch das Attribut resolvePath unterstützt, das dazu führt, dass nicht in der Breite, sondern genau die Objekte entlang des Pfades in die Ergebnismenge aufgenommen werden.
<wfs:Query typeNames="AX_Flurstueck">
<wfs:PropertyName resolve="local" resolvePath="istBestandteilVon/AX_Buchungsblatt">
istGebucht
</wfs:PropertyName>
</wfs:Query>
Das Element <wfsext:PropertyName> aus dem Schema "WFS-Erweiterungen" hat die- selbe Semantik wie das Element <wfs:PropertyName> aus dem WFS-Schema ohne das Attribut resolveDepth und erweitert dieses um zwei zusätzliche Fähigkeiten. Wird das Elemente mit dem Attribut resolvePath und 'this' als als Name der Eigenschaft verwendet, dann stelllt das Schlüsselwort 'this' eine Relation auf das Ausgangsobjekt selbst dar, so dass - anders als bei <wfs:PropertyName> aus dem WFS 2.0 Standard - der vollständige Relationspfad ausgehend von der Objektart der Query in resolvePath angegeben wird. Dies ermöglicht, dass alle darin enthaltenen Objektarten auf der Ebene instanziierbarer Objektarten angegeben werden können.
<wfs:Query typeNames="AX_Punktort_AU">
<wfsext:PropertyName resolve="local" resolvePath="istTeilVon/AX_Aufnahmepunkt/hat/AX_Sicherungspunkt">this</wfsext:PropertyName>
</wfs:Query>
Bei Verwendung des Elements <wfsext:PropertyName> ist die Angabe der letzten Zielobjektart im Relationspfad optional, d. h. sie kann weggelassen werden, damit sich im Falle einer abstrakten Zielobjektart alle abgeleiteten instanziierbaren Objektarten qualifizieren. Die folgende Query liefert alle neben allen Punktorten mit unabhängiger Geometrie auch alle zugehörigen Schwerefestpunkte sowie alle übrigen REOs und NREOs der Schwerefestpunkte zurück.
<wfs:Query typeNames="AX_Punktort_AU">
<wfsext:PropertyName resolve="local" resolvePath="istTeilVon/AX_Schwerefestpunkt/bestehtAus">this</wfsext:PropertyName>
</wfs:Query>
Des Weiteren kann durch die Angabe des Attributs 'leafOnly' mit dem Wert 'true' die Erweiterung der Ergebnismenge auf die Objekte am Ende des Pfads in resolvePath eingeschränkt werden. Die übrigen Objekte entlang des Pfads werden nicht zurückgeliefert. Die folgende Query hat dieselbe Wirkung wie die vorherige Query mit der Änderung, dass keine Schwerefestpunkte zurückgeliefert werden.
<wfs:Query typeNames="AX_Punktort_AU">
<wfsext:PropertyName resolve="local" leafOnly="true" resolvePath="istTeilVon/AX_Schwerefestpunkt/bestehtAus">this</wfsext:PropertyName>
</wfs:Query>
Sofern nur einzelne, ganz bestimmte nachgeordnete Objekte benötigt werden (in den Beispielen nur für wenige Punktorte die Punkte oder weitere Bestandteile der Punkte), dann bietet es sich i.d.R. an, die Selektion in zwei Abfragen aufzuteilen. Die erste Abfrage zur Selektion der Punktorte und anschließend die gezielte Selektion der benötigten Punkte.
Die nachfolgenden Tabellen geben einen Überblick, wie die Attribute resolve, resolveDepth und resolvePath das Ergebnis einer Flurstücks-Query beeinflussen können.
Die erste Tabelle verwendet dabei die Query nach dem Muster:
<wfs:Query typeNames="AX_Flurstueck">
<wfs:PropertyName resolve=[X1] resolveDepth=[X2] resolvePath=[X3]>istGebucht</wfs:PropertyName>
</wfs:Query>
| Wert [X1] von resolve | Wert [X2] von resolveDepth | Wert [X3] von resolvePath | Ergebnis |
|---|---|---|---|
(ohne Wert) |
(ohne Wert) |
(ohne Wert) |
AX_Flurstueck, eingeschränkt auf alle Pflichteigenschaften einschließlich <istGebucht xlink:href=urn:adv:oid:DE…/> mit Verweis auf die AX_Buchungsstelle. |
local |
1 |
(ohne Wert) |
AX_Flurstueck, eingeschränkt auf alle Pflichteigenschaften einschließlich <istGebucht xlink:href=urn:adv:oid:DE../> mit Verweis auf die AX_Buchungsstelle. Die AX_Buchungsstelle ist im Benutzungsergebnis enthalten. |
local |
2 |
(ohne Wert) |
AX_Flurstueck, eingeschränkt auf alle Pflichteigenschaften einschließlich <istGebucht xlink:href=urn:adv:oid:DE../> mit Verweis auf die AX_Buchungsstelle. Die AX_Buchungsstelle und alle damit direkt verbundenen Objekte, d.h. Objekte der Objektarten AX_Buchungsblatt (beziehtSichauf, istBestandteilVon), AX_Flurstueck (verweistAuf), AX_Buchungsstelle (zu, an, durch, hatVorgaenger), AX_Verwaltung, (wirdVerwaltetVon), usw. sind im Benutzungsergebnis enthalten. |
local |
(ohne Wert) |
istBestandteilVon/ AX_Buchungsblatt |
AX_Flurstueck, eingeschränkt auf alle Pflichteigenschaften einschließlich <istGebucht xlink:href=urn:adv:oid:DE../> mit Verweis auf die AX_Buchungsstelle. Die AX_Buchungsstelle und alle damit über die Eigenschaft istBestandteilVon direkt verbundenen AX_Buchungsblatt-Objekte sind im Ergebnis in feature collection enthalten. |
local |
(ohne Wert) |
(ohne Wert) |
Es gilt der Default resolveDepth=*, d.h. zurückgeliefert würde AX_Flurstueck, eingeschränkt auf alle Pflichteigenschaften einschließlich <istGebucht xlink:href=urn:adv:oid:DE../> mit Verweis auf die AX_Buchungsstelle. Die AX_Buchungsstelle und alle damit direkt oder indirekt verbundenen Objekte sind im Benutzungsergebnis enthalten. Achtung: Aufgrund der weitreichenden Verwendung von Relationen im AAA-Anwendungsschema kann der zurückgelieferte Datenumfang erheblich sein, bis hin zum gesamten Datenbestand. |
Es kann somit entweder nur 'resolvePath' oder nur 'resolveDepth' in einer Query verwendet werden, aber nicht beide gleichzeitig. Bei gleichzeitiger Angabe von 'resolvePath' und 'resolveDepth' ist letzterer Parameter zu ignorieren.
Die zweite Tabelle verwendet die Query nach dem Muster:
<wfs:Query typeNames="AX_Flurstueck">
<wfsext:PropertyName resolve=[X1] resolvePath=[X3] leafOnly=[X4]>this</wfsext:PropertyName>
</wfs:Query>
| Wert [X1] von resolve | Wert [X3] von resolvePath | Wert [X4] von leafOnly | Ergebnis |
|---|---|---|---|
local |
istGebucht/AX_Buchungsstelle |
(ohne Wert), true false |
AX_Flurstueck, eingeschränkt auf alle Pflichteigenschaften einschließlich <istGebucht xlink:href="urn:adv:oid:DE…"/> mit Verweis auf die AX_Buchungsstelle. Die AX_Buchungsstelle ist im Benutzungsergebnis enthalten. 'leafOnly' hat keine Auswirkungen. |
local |
istGebucht |
(ohne Wert), true, false |
Gleiches Ergebnis, alle Werte von 'istGebucht' sind Buchungsstellen. |
local |
istGebucht/AX_Buchungsstelle/istBestandteilVon/AX_Buchungsblatt |
(ohne Wert), false |
AX_Flurstueck, eingeschränkt auf alle Pflichteigenschaften einschließlich <istGebucht xlink:href="urn:adv:oid:DE…"/> mit Verweis auf die AX_Buchungsstelle. Die AX_Buchungsstelle und alle damit über die Eigenschaft 'istBestandteilVon' direkt verbundenen AX_Buchungsblatt-Objekte sind im Ergebnis in enthalten. |
local |
istGebucht/AX_Buchungsstelle/istBestandteilVon |
(ohne Wert), false |
Gleiches Ergebnis, alle Werte von 'istBestandteilVon' sind Buchungsblätter. |
local |
istGebucht/AX_Buchungsstelle/istBestandteilVon/AX_Buchungsblatt |
true |
AX_Flurstueck, eingeschränkt auf alle Pflichteigenschaften einschließlich <istGebucht xlink:href="urn:adv:oid:DE…"/> mit Verweis auf die AX_Buchungsstelle. Die mit der AX_Buchungsstelle über die Eigenschaft 'istBestandteilVon' direkt verbundenen AX_Buchungsblatt-Objekte sind im Ergebnis enthalten. Die Buchungsstelle ist selbst nicht im Ergebnis enthalten. |
local |
istGebucht/AX_Buchungsstelle/istBestandteilVon |
true |
Gleiches Ergebnis, alle Werte von 'istBestandteilVon' sind Buchungsblätter. |
Bei 'Benutzungsergebnissen' erfolgt innerhalb einer <FeatureCollection> keine Klammerung in einer Ergebnismenge <AdditonalObjekts> für die zusätzlich über resolve, resolveDepth und resolvePath selektierten Objekte.
In der NAS werden alle Relationen nur in einer, der im UML-Modell als navigierbar ausgezeichneten Richtung repräsentiert. Die folgende Query erfragt alle Flurstücke und die Buchungsstellen unter denen diese gebucht sind:
<wfs:Query typeNames="AX_Flurstueck">
<wfsext:PropertyName resolve="local" resolvePath="istGebucht/AX_Buchungsstelle/istBestandteilVon/AX_Buchungsblatt">this</wfsext:PropertyName>
</wfs:Query>
Oder im Fall, dass ein Flurstück bekannt ist, dann kann aus dem <istGebucht>-Element der Identifikator der Buchungsstelle extrahiert werden (der String nach dem "urn:adv:oid:"-Präfix, in diesem Beispiel "DEBY123412345678") und die Buchungsstelle wie folgt erfragt werden:
<wfs:Query typeNames="AX_Buchungsstelle">
<fes:Filter>
<fes:ResourceId rid="DEBY123412345678"/>
</fes:Filter>
</wfs:Query>
In umgekehrter Richtung, d.h. von der Buchungsstelle zum Flurstück ist die Relation zwar auch benannt ("grundstueckBestehtAus"), aber nicht in der NAS repräsentiert. Sollen nun die Flurstücke ermittelt werden, die über "istGebucht" einer bestimmten Buchungsstelle (im Beispiel wird wieder die ID "DEBY123412345678" verwendet) zugeordnet sind, so kann dies über die Prüfung der Relation erfolgen:
<wfs:Query typeNames="AX_Flurstueck">
<fes:Filter>
<fes:PropertyIsEqualTo>
<fes:ValueReference>istGebucht/AX_Buchungsstelle/gml:identifier</fes:ValueReference>
<fes:Literal>urn:adv:oid:DEBY123412345678</fes:Literal>
</fes:PropertyIsEqualTo>
</fes:Filter>
</wfs:Query>
Eine äquivalente Abfrage (sofern sich Flurstück und Buchungsstelle in derselben lokalen Datenbasis befinden) ist
<wfs:Query typeNames="AX_Flurstueck">
<fes:Filter>
<fes:PropertyIsEqualTo>
<fes:ValueReference>istGebucht/AX_Buchungsstelle/@gml:id</fes:ValueReference>
<fes:Literal>DEBY123412345678</fes:Literal>
</fes:PropertyIsEqualTo>
</fes:Filter>
</wfs:Query>
Eine Möglichkeit so etwas wie wfsext:PropertyName mit resolvePath auch in inverser Richtung, also das gleichzeitige Selektieren bestimmter Buchungsstellen und aller Flurstücke, die auf diese gebucht sind, besteht durch die Möglichkeit der Verwendung inverser Relationen in Filterausdrücken. Hier kann die Selektion stattdessen natürlich auch in zwei Schritten, d.h. über zwei Queries, erfolgen.
In aller Regel werden mehrere Queries erforderlich sein, um sich die Objekte aus dem Datenbestand zu besorgen, die für komplexere Abfragen benötigt werden. Hierbei wird aus den Ergebnissen der vorigen Query die neue Query formuliert. Sehr häufig werden hierbei Zugriffe auf die Katalogeinträge zum Entschlüsseln von Schlüsselwerten erforderlich sein.
In der NAS ist es unzulässig in einer WFS-Query durch die Angabe mehrerer Objektarten im Parameter 'typeNames' eine Verknüpfung als JOIN zu realisieren, auch wenn es diese Möglichkeit im WFS-Standard 2.0 gibt.
5.1.3. Erweiterungen der OGC Standards
Zur Codierung von Selektionskriterien wird das <wfs:Query>-Element aus der Spezifikation "Web Feature Service, Version 2.0.2" in Verbindung mit den Festlegungen der Spezifikation "Filter Encoding, Version 2.0.2" des Open Geospatial Consortiums verwendet. In OGC wird üblicherweise die Version nur bis zur zweiten Stelle referenziert (z.B. WFS 2.0, GML 3.2). Anzuwenden ist dann jedoch jeweils der letzte Bugfix, der über die dritte Stelle versioniert wird, bei WFS 2.0 beispielsweise WFS 2.0.2.
Die Anforderungen an die Selektions- bzw. Filterfunktionalität von AFIS-ALKIS-ATKIS gingen in früheren GeoInfoDok-Versionen über die in den dabei zugrundeliegenden Versionen der OGC-Spezifikationen beschriebenen Funktionalitäten hinaus. Deshalb wurden bislang zusätzlich einige Erweiterungen festgeschrieben, die mit dieser Version nicht mehr erforderlich sind:
-
Über das matchAction-Attribut kann bei multiplen Objekteigenschaften inzwischen gesteuert werden, wie das Verhalten sein kann. Das für die GeoInfoDok vorgegebene Verhalten ist inzwischen das Standardverhalten des WFS (matchAction="Any").
Das Verhalten von matchAction soll an einem einfachen Beispiel erläutert werden. Nehmen wir ein AX_Gebaeude mit den folgenden weiteren Gebäudefunktionen: 1010 (Hotel) und 1050 (Spielcasino).
Verwendet wird die Query nach dem Muster
<wfs:Query typeNames="AX_Gebaeude"> <fes:Filter> <fes:PropertyIsEqualTo matchAction="..."> <fes:ValueReference>weitereGebaeudefunktion</fes:ValueReference> <fes:Literal>1050</fes:Literal> </fes:PropertyIsEqualTo> </fes:Filter> </wfs:Query>Das Ergebnis der Query in Abhängigkeit von matchAction wird in folgender Tabelle erläutert.
| Wert von matchAction | Ergebnis |
|---|---|
Any |
Das AX_Gebaeude wird im Ergebnis zurückgeliefert, da mindestens ein Attribut weitereGebaeudefunktion den Wert 1050 hat. |
All |
Das AX_Gebaeude wird im Ergebnis nicht zurückgeliefert, da nicht alle Attribute weitereGebaeudefunktion den Wert 1050 haben, sondern auch 1010 vorkommt. |
One |
Das AX_Gebaeude wird im Ergebnis zurückgeliefert, da genau ein Attribut weitereGebaeudefunktion den Wert 1050 hat. |
(ohne Wert) |
Das AX_Gebaeude wird im Ergebnis zurückgeliefert, da "Any" der Standardwert ist. |
-
Das Element <wfsext:XlinkPropertyName> ist nicht länger erforderlich, wfs:PropertyName mit den Attributen resolve="local" und resolveDepth="1"hat dieselbe Wirkung wie bisher wfsext:XlinkPropertyName mit dem Attribut traverseXlinkDepth.
-
Das Element <wfsext:XlinkPropertyPath> wird durch wfs:PropertyName oder wfsext:PropertyName mit den Attributen resolve="local" und resolvePath ersetzt (siehe unten TBD: Genaue Referenz?). Das Element wfsext:PropertyName hat weitgehend die Wirkung wie bisher wfsext:XlinkPropertyPath.
Hinweis: Der Grund für die Verwendung des GeoInfoDok-spezifischen Elements wfsext:PropertyName mit resolvePath statt wfs:PropertyName mit resolvePath ist folgender: Ist die Zielobjektart der im Inhalt des Elements <wfs:PropertyName> angegebenen Relationsart eine abstrakte Objektart und beginnt der weitere in resolvePath angegebene Relationspfad mit einer Relationsart, die in einer davon abgeleiteten Objektart definiert ist, dann ergibt sich insgesamt ein mehrdeutiger Relationspfad. Das Verhalten der Implementierung ist in diesem Fall undefiniert. Das Element wfsext:PropertyName mit vollständigem Pfad im Attribut resolvePath vermeidet diese Probleme.
-
Die Definition eines <wfsext:Replace>-Elements für Transaktionen ist nicht weiter erforderlich, da WFS 2.0.2 ein entsprechendes Element unterstützt.
Darüber hinaus verwendet die GeoInfoDok noch einige wenige Festlegungen, die in dieser Form kein Bestandteil der oben genannten Spezifikationen sind:
-
Assoziationen können standardmäßig entweder über das Einbetten des referenzierten Objekts oder über einen "xlink:href"-Verweis zu diesem ausgedrückt werden. Beide Darstellungen sind hierbei semantisch grundsätzlich vollkommen äquivalent:
NoteZur einfacheren Interpretierbarkeit der NAS-Dateien ist die Verwendung der 2. Darstellung in der NAS explizit vorgeschrieben.
Darstellung 1:
<AX_Flurstueck> <istGebucht> <AX_Buchungsstelle gml:id="DEXXXX00000001"> <zu> <AX_Buchungsstelle gml:id="DEXXXX00000002"> <laufendeNummer>1</laufendeNummer> </AX_Buchungsstelle> </zu> </AX_Buchungsstelle> </istGebucht> </AX_Flurstueck>Darstellung 2:
<AX_Flurstueck> <istGebucht xlink:href="urn:adv:oid:DEXXXX00000001"/> </AX_Flurstueck> <AX_Buchungsstelle gml:id="DEXXXX00000001"> <zu xlink:href="urn:adv:oid:DEXXXX00000002"/> </AX_Buchungsstelle> <AX_Buchungsstelle gml:id="DEXXXX00000002"> <laufendeNummer>1</laufendeNummer> </AX_Buchungsstelle>Für die erste Darstellung ist eine explizite Verfolgung der Objekt-Assoziationen durch den "/"-Operator von Xpath in einem Web Feature Service bereits explizit erlaubt. Da diese Darstellungen semantisch äquivalent sind, wird explizit erlaubt, den "/"-Operator auch auf xlink:href-Verweise wirken zu lassen, wobei hier bis auf weiteres nur lokal auflösbare xlink:href-Verweise unterstützt werden müssen. Das bedeutet, dass z.B. eine Abfrage über die Flurstücke, deren Buchungsstelle über die "zu"-Relation mit einer anderen Buchungsstelle mit der laufenden Nummer "1" verbunden ist, wie folgt formuliert werden kann:
<wfs:Query typeNames="AX_Flurstueck"> <fes:Filter> <fes:PropertyIsEqualTo> <fes:ValueReference>istGebucht/AX_Buchungsstelle/zu/AX_Buchungsstelle/laufendeNummer</fes:ValueReference> <fes:Literal>1</fes:Literal> </fes:PropertyIsEqualTo> </fes:Filter> </wfs:Query>Verwendung von
<wfs:PropertyName>mit AttributenresolveDepthbzw.resolvePathDie Verwendung ist innerhalb der Queries im Benutzungsauftrag sowie in den Nutzerprofilen erlaubt. Hierbei werden insbesondere die folgenden Regelungen festgehalten:
-
Sofern das Anwendungsschema (wie im Fall der NAS) fordert, dass die Objekt-Assoziationen nicht inline, sondern stets über xlink-Verweise angebunden sind, führt ein xlink-Traversal dazu, dass das referenzierte Objekt in der Ergebnismenge enthalten sind.
-
Die Auflösung von href-Verweisen unterstützt im Fall der NAS explizit die URN-Identifikatoren des AAA-Modells.
-
Eine Auflösung von href-Verweisen erfolgt nur für lokal verfügbare Ressourcen.
-
-
Verwendung von
<wfsext:PropertyName>mit den Attributen resolve="local", resolvePath und optional 'leafOnly'. Das Verhalten ist identisch zur Verwendung von<wfs:PropertyName>mit den folgenden Unterschieden:-
Als Inhalt des Elements kann das Schlüsselwort 'this' verwendet werden. Es stellt jeweils eine Relation von den Objektinstanzen der Ergebnismenge auf sich selbst dar. In 'resolvePath' wird bei der Verwendung von 'this' immer der vollständige Relationspfad bezogen auf die in der Query im Attribut 'typenames' angefragte Objektart angegeben. Die Objektart am Ende des Relationspfades in 'resolvePath' ist bei der Verwendung von 'this' optional. Wird sie nicht angegeben und ist das Ziel der letzten Relationsart eine abstrakte Objektart, dann qualifizieren sich alle daraus abgeleiteten Objektarten.
Durch die Angabe des Attributs 'leafOnly' mit dem Wert 'true' kann zusätzlich die Erweiterung der Ergebnismenge auf die Objekte am Ende des Pfads in resolvePath eingeschränkt werden. Die übrigen Objekte entlang des Pfads werden nicht zurückgeliefert. Hinweis: In der GeoInfoDok 6.0.1 wurden diese WFS-Erweiterungen über das Element
<wfsext:XlinkPropertyPath>realisiert. -
-
Verwendung von
<wfsext:PropertyIsOfType>zur Prüfung des Typs einer Objekteigenschaft. Bei Eigenschaften mit complexContent ist dies der qualifizierte Elementname des Kindelements, bei Eigenschaften mit simpleContent der qualifizierte Typname des Eigenschaftselements.Wenn der Typ der Objekteigenschaft
gml:ReferenceTypeist, ermittelt<wfsext:PropertyIsOfType>den qualifizierten Elementnamen des referenzierten Objekts (dessen Objektart).Beispiele unter Verwendung der Objektart AX_Flurstueck und "adv" als Namespacepräfix für die NAS und "xs" als Namespacepräfix für XML Schema:
-
Beim Attribut 'flurstuecksnummer', das einen Datentyp als Wert hat, liefert der Operator als Wert 'adv:AX_Flurstuecksnummer'.
-
Beim Attribut 'flurstueckskennzeichenKennung' (Attribut mit einem einfachen Wert) ist es 'xs:string'.
-
Bei der Relationsart 'istGebucht' ist es 'adv:AX_Buchungsstelle'.
Besonders nützlich ist der Operator bei Fällen, wo der Wert der Relationsart eine abstrakte Objektart ist. Bei Punktorten ermöglicht der Operator beispielsweise das Filtern anhand der Art des Punktes (der Wert bei 'istTeilVon' ist der Elementname des referenzierten ZUSOs, also z.B. 'adv:AX_Sicherungspunkt').
-
5.1.4. Ausgabe von Benutzungsdaten
Die Ausgabe von Benutzungsdaten ist eine Datenausgabe ohne explizite Angabe einer im aufnehmenden System auszuführenden Funktionalität. Eine spezielle Aufbereitung der Daten in Abhängigkeit von der Ausgabeanforderung (z.B. Herstellung der "flurstückszentrierten Sicht" in ALKIS) ist möglich, indem entsprechende temporäre Objekte ausgegeben werden.
Für das Ergebnis einer Benutzung wird die wfs:FeatureCollection aus dem Web Feature Service von OGC verwendet und für AAA entsprechend um weitere Informationen ergänzt. Für jede Art der Ausgabe wird je nach Benutzungsauftrag eine eigene Schema-Datei verwendet.
5.1.5. Führung von Sekundärnachweisen
Die Führung von Sekundärnachweisen erfolgt über die Nutzerbezogene Bestandsdatenaktualisierung fallbezogen oder stichtagsbezogen. Die nachfolgenden Regelungen gelten unabhängig davon, ob das NBA-Verfahren stichtags- oder fallbezogen erfolgt.
Im Fall einer Führung der Sekundärdatenbank ohne vollständigen Historiennachweis, d.h. es ist in der Sekundärdatenbank stets nur der aktuelle Stand der Daten verfügbar, gelten die folgenden Regeln:
-
Die Operationen <wfs:Insert>, <wfs:Replace> und <wfs:Delete> werden sinngemäß wie bei der Führung von Primärnachweisen ohne vollständigen Historiennachweis durch das aufnehmende System ausgeführt.
Im Fall einer Führung der Sekundärdatenbank mit vollständigem Historiennachweis, d.h. es werden in der Sekundärdatenbank zumindest temporär auch untergegangene Objekte und Objektversionen vorgehalten, gelten die folgenden Regeln:
-
Die Operationen <wfs:Insert> und <wfs:Replace> werden sinngemäß wie bei der Führung von Primärnachweisen mit vollständigem Historiennachweis durch das aufnehmende System ausgeführt.
Ausnahme: Da in der Sekundärdatenhaltung Objektidentifikatoren und der Beginn des Lebenszeitintervalls der neuen Objektversionen nicht vom System vergeben werden, müssen diese abweichend zur Regelung bei der Fortführung von Primärnachweisen aus dem Attribut "@gml:id" bzw. dem Element "lebenszeitintervall/AA_Lebenszeitintervall/beginnt" übernommen werden.
-
In dem Fall, dass ein Objekt untergeht ("historisiert" wird), ist statt des <wfs:Delete>-Operators der ansonsten in der NAS nicht unterstützte <wfs:Update>-Operator verwendet. Mit dem Update dürfen ausschließlich die folgenden Eigenschaften verändert werden:
-
"lebenszeitintervall/AA_Lebenszeitintervall/endet" mit dem Zeitpunkt an dem die letzte Version des Objekts in der Primärdatenbank untergegangen ist. Die Fortschreibung dieser Eigenschaft muss bei jeder <wfs:Update>-Operation erfolgen.
-
"anlass" mit dem Entstehungs- und Untergangsanlass. Hierfür sind zwei <wfs:Property>-Elemente, jeweils mit dem qualifizierten Namen "anlass" zu verwenden; <wfs:Value> im ersten <wfs:Property>-Element ist der Entstehungsanlass, <wfs:Value> im zweiten <wfs:Property>-Element der Untergangsanlass. Diese Angaben sollen nur erfolgen, sofern in der Primärdatenbank ein Untergangsanlass vergeben wurde.
Beispiel:
<wfs:Update typeName="adv:AX_Flurstueck"> <wfs:Property> <wfs:ValueReference>adv:lebenszeitintervall/adv:AA_Lebenszeitintervall/adv:endet</wfs:ValueReference> <wfs:Value>2007-11-13T12:00:00Z</wfs:Value> </wfs:Property> <wfs:Property> <wfs:ValueReference>adv:anlass</wfs:ValueReference> <wfs:Value>000000</wfs:Value> </wfs:Property> <wfs:Property> <wfs:ValueReference>adv:anlass</wfs:ValueReference> <wfs:Value>010102</wfs:Value> </wfs:Property> <fes:Filter> <fes:ResourceId rid="DEBY123412345678"/> </fes:Filter> </wfs:Update>
Da in der Sekundärdatenhaltung nie eine Aktualitätsprüfung erfolgt, wird für die Führung von Sekundärnachweisen abweichend von der Führung von Primärnachweisen festgelegt, dass das Attribut rid des Filterausdrucks im <wfs:Delete>-, <wfs:Replace>- oder <wfs:Update>-Element nie um die Angabe des Entstehungsdatums/-zeit der vorhandenen Version ergänzt wird.
Diese Definitionen wurden so gewählt, dass möglichst weitgehend ein bestehender Web Feature Service ohne zusätzliche Anpassungen verwendet werden kann - insbesondere im Fall ohne Historienführung. Es ist allerdings erforderlich, dass der Web Feature Service die <wfs:Replace>-Operation der GeoInfoDok unterstützt.
Wenn eine Sekundärdatenhaltung NBA-Abgaben an ein Tertiärsystem vornehmen soll, muss diese sicherstellen, dass alle Aufnahmen aus Primärsystemen auch berücksichtigt werden. Können bei der Abgabe der Daten aus Primärsystemen an eine Sekundärdatenhaltung nicht alle Daten übernommen werden, gibt es 2 Möglichkeiten:
-
Die Sekundärdatenhaltung muss bis zu einer Abgabe an ein Tertiärsystem warten bis alle Datenlieferungen aus den Primärsystemen übernommen werden können.
-
Die Sekundärdatenhaltung gibt nur die bisher von Primärsystemen übernommenen Daten an ein Tertiärsystem weiter. Sind die fehlenden Daten im Sekundärsystem übernommen, ist sicherzustellen, dass diese im nächsten Lieferzyklus an das Tertiärsystem weitergereicht werden. Dies kann z. B. in der Implementierung durch die Vergabe eines technischen Datums bei der NBA-Übernahme und Auswertung der NBA-Abgabe erfolgen.
Um die unterschiedlichen Kundenanforderungen erfüllen zu können, ist bei Bedarf die entsprechende Möglichkeit in den Verfahrenslösungen zu implementieren.
5.1.6. Sperren und Entsperren von Objekten
Sperraufträge ermöglichen das Sperren von Objekten im Führungssystem gegen Fortführungen von Dritten durch Angabe einer Liste mit Objekt-Identifikatoren. Entsperraufträge heben die Sperrung wieder auf. Objekte mit Stereotype und Tagged Value "retired" können weder gesperrt noch entsperrt werden.
5.1.7. Reservierungen
Zur Reservierung von Kennungen (z.B. für Vermessungspunkte, Flurstückskennzeichen, etc.) können entsprechende Aufträge an ein Führungssystem formuliert werden. In der Ergebnis-Datei erhält man eine Liste mit den angeforderten Kennungen.
5.1.8. Übermittlung von Protokollinformationen
Da für jede Operation der NAS sowohl eine Request- als auch eine Response-Klasse definiert wurden, wird in letzterer definiert, welche Protokollinformation bei der jeweiligen Operation ausgegeben wird. Sie sind somit in den bei den einzelnen Operationen enthalten.
5.2. Auszutauschende Einheiten
Die kleinsten Einheiten des Datenaustauschs sind vollständige Fachobjekte. Dies gilt grundsätzlich auch für die Fortführung des Primärnachweises (AAA-Führungssystem). Unabhängig davon, ob sich Objekte durch eigene Eigenschaften zur Ausgabe qualifiziert haben oder über die Auswertung einer vorgegebenen Selektionskette zur Ausgabe qualifiziert wurden, sind sie hinsichtlich der Fortführungsfunktionalität grundsätzlich als eigene fortzuführende Einheit zu betrachten (Ausnahmen siehe Abschnitt "Erläuterungen zu ALKIS" TBD: Genaue Referenz?).
Benutzungen, die nicht dem Zweck der Fortführung des Primärnachweises dienen, können, je nach Nutzerwunsch oder Nutzerprofil, unvollständige Fachobjekte (fehlende Attribute oder Relationen) oder durch spezielle Aufbereitung der Daten entstandene "temporäre Objekte" für den Datenaustausch erzeugen.
Der Datenaustausch erfolgt in der NAS unabhängig vom konzeptuellen Modell der Versionierung (Behälter mit Versionen) so, als ob alle Objektversionen unabhängige Objekte wären. Auf diese Art und Weise ist es möglich, die Austauschschnittstelle für Stellen, die eine vollständige Historie führen und solche, die dies nicht tun, identisch zu definieren. Dabei sind jedoch folgende Rahmenbedingungen zu beachten:
-
Damit die Zahl der entstehenden Versionen reduziert wird, müssen zweiseitige Relationen im Datenaustausch durch eine einzige einseitige Relation dargestellt werden. Es wird diejenige Relation im Datenaustausch codiert, die im UML-Schema als bevorzugte Navigationsrichtung definiert wurde. Zweiseitige Relationen in genormten Schemata werden mittels geeigneten Parametrisierung durch einseitige ersetzt.
-
Um beim Datenaustausch die zu löschende oder zu überschreibende bzw. zu versionierende Version eines Objekts eindeutig identifizieren zu können, wird in der Austauschdatei der Identifikator in den XML-<Delete>- und -<Replace>-Elementen um Entstehungsdatum/-zeit ergänzt. Die Ergänzung des Identifikators um den Zeitstempel ist nur im Datenaustausch erforderlich, um sicherzustellen, dass sich Fortführungen auch auf den aktuellen Datenbestand beziehen. Im Datenbestand selbst werden die zu referenzierenden Versionen durch Auswertung des Lebenszeitintervalls der Versionen auf attributiver Ebene gewonnen.
5.3. Implizite Funktionalität
Bei der Führung von Primär- und Sekundärnachweisen über die Schnittstelle NAS ist es erforderlich, dass das aufnehmende System neben der Ausführung der expliziten Funktionen <Insert>, <Delete> und <Replace> auch über implizite Funktionen verfügt, die erst die komfortable Arbeitsweise mit dem System erlauben.
Der Umfang der zu realisierenden impliziten Funktionalität eines Datenhaltungssystems ist für ein System zum Primärnachweis und zum Sekundärnachweis unterschiedlich groß. Die von einem Sekundärnachweissystem beim Datennutzer zu fordernden Funktionen sollten grundsätzlich möglichst gering sein, damit eine einfache Implementierung ermöglicht wird. Demgegenüber kann ein Datenhaltungssystem für den Primärnachweis bei der originär zuständigen datenführenden Stelle über wesentlich mehr Funktionen verfügen.
5.3.1. Implizite Funktionalität eines Systems für den Primärnachweis
Bei der Nutzung der NAS für die Kommunikation zwischen einem Qualifizierungs- bzw. Erfassungssystem und einem Führungssystem sind folgende implizite Funktionen notwendig:
-
Das aufnehmende System leitet beim Eintrag neuer Versionen das Entstehungsdatum/-zeit aus der Systemzeit ab. Alle in einem Fortführungsfall eingetragenen (oder durch die Funktion <Replace> entstandenen) neuen Versionen erhalten dasselbe Entstehungsdatum/-zeit. Dies ist i.d.R. die Zeit, an der die Transaktion begonnen wird (commit). Besteht ein Auftrag aus Teilaufträgen (Fortführungsfällen), werden diese in der Reihenfolge ihres Auftretens in der NAS-Datei abgearbeitet. Für jeden Teilauftrag wird ein eigenes Entstehungsdatum/-zeit vergeben.
-
Referenzen werden beim Datenaustausch über die NAS nur einseitig in der bevorzugten Richtung der Referenz ausgetauscht. Das aufnehmende System baut die Gegenreferenz implizit auf. Durch den Aufbau der Gegenreferenz entsteht keine neue Version.
-
Es gibt Fachobjekte, die nur dann eine Existenzberechtigung haben, wenn sie von anderen Objekten referenziert werden (z.B. Objekte vom Typ Lage). Weil Gegenreferenzen nicht über die NAS übermittelt werden, kann ein fortführendes System dann nicht wissen, ob ein Objekt, das durch die Fortführung nicht mehr referenziert wird auch gelöscht werden kann. Das nicht mehr referenzierte Fachobjekt muss durch die Datenbank gelöscht werden. Die Fachobjekte, die wegen fehlender Referenzierung gelöscht werden können, sind im Objektartenkatalog zu bezeichnen. Dieser Fortführungsfall findet Eingang in die Versionierung und Historisierung.
-
Es gibt Fachobjekte, die Objekte referenzieren, die im Rahmen der Fortführung gelöscht werden sollen. Weil Gegenreferenzen nicht über die NAS übermittelt werden, kann ein fortführendes System nicht wissen, ob ein zu löschendes Objekt durch weitere Objekte referenziert wird. Dadurch kann es vorkommen, dass Referenzen nach der Fortführung nicht mehr befriedigt werden. Das Datenhaltungssystem muss solche unbefriedigten Referenzen automatisch löschen. Dieser Fortführungsfall findet Eingang in die Versionierung und Historisierung.
-
Es gibt Fachobjekte, die nur dann eine Existenzberechtigung haben, wenn sie andere Fachobjekte referenzieren (z.B. Präsentationsobjekte). Werden im Rahmen einer Fortführung alle solchen Referenzen explizit oder implizit gelöscht, so löscht das Datenhaltungssystem automatisch das entsprechende Fachobjekt, dem die notwendigen Referenzen fehlen. Die Fachobjekte, die wegen fehlender notwendiger Referenzen gelöscht werden müssen, sind im Objektartenkatalog zu bezeichnen. Dieser Fortführungsfall findet Eingang in die Versionierung und Historisierung.
-
Werden im Zuge einer Fortführung nur die fachlich geänderten Objekte angeliefert, muss die Datenbank ggf. die topologische und geometrische Konsistenz selbstständig herstellen (Geometriebehandlung).
-
Beim Löschen von Geometrien sind ggf. Zerschlagungen aus vorherigen Implizitprozessen nach folgender Regel wieder rückgängig zu machen. Eine Position wird aus der Geometrie aller Objekte entfernt, wenn sie in keinem Objekt, in dem sie verwendet wird zur geometrischen Definition dieses Objektes beiträgt; trägt sie auch nur in einem Objekt zur geometrischen Definition bei, bleibt sie in allen Objekten erhalten. Eine Position trägt dann zur geometrischen Definition eines Objekts bei, wenn das Objekt punktförmigen Raumbezug hat, oder wenn sie (bei linienhaftem oder flächenhaftem Raumbezug) nicht in einer Geraden mit der vorhergehenden und der folgenden Position liegt. Der Begriff "liegt in der Geraden" ist dabei in Abhängigkeit von der festgelegten Koordinatenauflösung (für metrische Lagekoordinaten in AFIS-ALKIS-ATKIS: Millimeter) zu definieren. Dieses Implizitverhalten führt im aufnehmenden System zu Fortführungen, die im auslösenden Fortführungsauftrag aus der NAS nicht explizit angegeben sind. Diese Fortführungen sind durch das aufnehmende System implizit zu veranlassen und führen zur Erzeugung neuer Versionen aller beteiligten Objekte.
-
Werden zur Fortführung eines Primärnachweises Austauschelemente mit vorläufigen Identifikatoren angeliefert, erzeugt das aufnehmende System endgültige eineindeutige Identifikatoren.
-
Beim Löschen von Flurstücken in Systemen mit vollständigem Historiennachweis wird der erste Fortführungsanlass aus dem Attribut "ueberschriftImFortfuehrungsnachweis" der Objektart AX_Fortfuehrungsfall in die untergehende Version des Flurstücks als zusätzlicher Untergangsanlass in das Attribut "Anlass" übernommen.
-
Bei den Stellen, die keine vollständige Historie führen, erzeugt die Datenhaltung beim Löschen eines aktuellen Flurstücks automatisch das entsprechende Objekt "Historisches Flurstück". Dabei ist der erste Fortführungsanlass aus dem Attribut "ueberschriftImFortfuehrungsnachweis" der Objektart AX_Fortfuehrungsfall als zusätzlicher Untergangsanlass in das Attribut "Anlass" zu übernehmen.
-
Weitere implizite Funktionen (z.B. Vergabe von Punktkennzeichen) sind implementierungsspezifisch.
Geometriebehandlung
Geometriebehandlung stellt eine Funktionalität der Datenbank (AAA-Führungskomponente) im Rahmen der Fortführungsverarbeitung dar. Dabei werden neue bzw. geänderte Geometrien so mit dem Altbestand verknüpft, dass bei geometrischen Identitäten zwischen Alt- und Neubestand in Abhängigkeit von der Themenzugehörigkeit der beteiligten Objekte redundanzfreie Geometrien entstehen.
Diese Funktionalität ist unabhängig von den Geometrie behandelnden bzw. Identitäten herstellenden Funktionen des Verarbeitungssystems (AAA-Verarbeitungskomponente) immer dann notwendig, wenn vom Verarbeitungssystem im Rahmen einer Fortführung nicht alle von geometrischen Operationen betroffenen Objekte an die AAA-Führungskomponente geliefert werden (z.B. bei einer Flurstückszerlegung nur das gelöschte und die neuen Flurstücke). Für die Geometriebehandlung gelten folgende Grundsätze:
-
Die Funktionalität der Geometriebehandlung kann von AAA-Führungssystemen optional realisiert werden. AAA-Verarbeitungskomponenten können ggf. von einer vorhandenen Geometriebehandlung in der AAA-Führungskomponente Gebrauch machen. Sofern in der AAA-Führungskomponente keine Geometriebehandlung realisiert ist, müssen die AAA-Verarbeitungskomponenten vollständige Daten anliefern. Unberührt davon ist die Verpflichtung der AAA-Führungskomponente zur Prüfung der Daten auf (geometrische) Konsistenz.
-
Die durch Geometriebehandlung implizit veränderten Objekte werden versioniert.
-
Die Geometriebehandlung beschränkt sich auf Klassen-Themen; eine Geometriebehandlung bei individuell gewollten Geometrieidentitäten ist nicht vorgesehen. Insofern wirkt sich eine Geometriebehandlung bei Klassen-Themen auch nicht auf Instanzen aus, für die Geometrieidentitäten individuell festgelegt wurden (keine "kaskadierende" Geometriebehandlung).
-
Bei individuell festgelegter, gewollter Geometrieidentität von Instanzen hat die AAA-Verarbeitungskomponente dafür zu sorgen, dass a) bei gewollter Identität (redundanzfreie Geometrie) ggf. ein Aufsplitten der Linien erfolgt und b) alle betroffenen Objekte im Fortführungsauftrag mitgeliefert werden.
-
AX_Fortfuehrungsauftrag wird um einen Steuerparameter (Geometriebehandlung ja/nein) ergänzt. Die AAA-Führungskomponente muss diesen Schalter auswerten und entsprechend reagieren, d.h. entweder die Geometriebehandlung ein- bzw. ausschalten oder den Fortführungsauftrag ablehnen. Die AAA-Verarbeitungskomponente hat dafür zu sorgen, dass die Schalterstellung dem Inhalt des Fortführungsauftrags entspricht.
-
Eine Geometriebehandlung bei aufnehmenden Systemen im NBA-Verfahren wird nicht vorgesehen/erwartet. Es werden alle veränderten Objekte übermittelt, auch die, die lediglich durch Geometriebehandlung in der AAA-Führungskomponente geändert wurden.
Es gelten folgende geometrische Kriterien:
-
Das Such- bzw. Trennkriterium für die Geometriebehandlung beträgt Wurzel 2 [mm].
-
An der Geometriebehandlung nehmen Punkte/Stützpunkte und Linien teil.
-
Bei Linien nehmen nur Geraden und Kreisbögen/Vollkreise an der Geometriebehandlung teil. Splines nehmen nicht an der Geometriebehandlung teil; hier muss die Verarbeitungskomponente dafür sorgen, dass alle betroffenen Objekte fortgeführt werden.
-
Auch wenn eine Neulinie eingetragen wird, muss ein "darunter liegender" Altpunkt die Neulinie splitten. Diese muss über den Altpunkt geführt werden.
Eine Tabelle mit einer Zusammenstellung der Impliziten Funktionen im Führungsprozess für ein System zum Primärnachweis befindet sich in Abschnitt A.2 dieses Dokumentes.
5.3.2. Implizite Funktionalität eines Systems für den Sekundärnachweis
Bei der Führung von Sekundärnachweisen über die Schnittstelle NAS baut das aufnehmende System (soweit vom Nutzer gewünscht) die Gegenreferenzen zu den ausgetauschten Referenzen auf und pflegt sie.
Replace-Befehle, bei denen das fortzuführende Objekt noch nicht im Datenbestand des Nutzers ist, sind bei der Übernahme wie Insert-Befehle zu behandeln. (Beispiel: Ein Nutzer erhält im Interessengebiet alle Flurstücke und die zugehörigen Eigentümer. Ein Flurstück wechselt seinen Eigentümer. Der Eigentümer ist aus Sicht des Nutzers neu (Insert) aus Sicht des ALKIS-Führungssystems aber alt (Replace), weil er bereits an Flurstücken außerhalb des Interessengebiets Eigentum hatte und deshalb seit langem im abgebenden System geführt wird, jedoch noch nie im System des Nutzers geführt wurde.)
Insert-Befehle, bei denen das einzutragende Objekt im Datenbestand des Nutzers bereits vorhanden ist, sind bei der Übernahme zu ignorieren. Ein aufnehmendes System muss Objektversionen verarbeiten können, deren Lebenszeitbeginn vor dem Intervallbeginn des NBA-Verfahrens liegt und im Abgabezeitraum nicht verändert wurde.
Eine Objektversion kann durch die neue Abgabeform mit gleichem Lebenszeitbeginn in unterschiedlichen Folgeabgaben auftauchen. Das aufnehmende System muss daher identische Versionen bei der Übernahme erkennen und ignorieren.
Eine Tabelle mit einer Zusammenstellung der Impliziten Funktionen im Führungsprozess für ein System zum Sekundärnachweis befindet sich in Abschnitt A.3 dieses Dokumentes.
5.4. Nutzerbezogene Bestandsdatenaktualisierung (NBA)
In diesem Abschnitt wird klargestellt, dass die folgenden Modi gemäß der Enumeration AX_Art_BereichZeitlich unterschieden werden müssen:
-
Selektion der abzugebenden Änderungen:
-
"stichtagsbezogen": Differenzdaten zwischen letzter erfolgreicher Datenabgabe und Stichzeitpunkt
-
"fallbezogen": alle Änderungen zwischen letzter erfolgreicher Datenabgabe und Stichzeitpunkt
-
-
Codierung der Änderungen in Abhängigkeit von einer Führung eines Historiennachweises im aufnehmenden System:
-
"ohne Historie": in der Sekundärdatenbank ist stets nur der aktuelle Stand der Daten verfügbar
-
"mit Historie": in der Sekundärdatenbank werden zumindest temporär auch untergegangene Objekte und Objektversionen vorgehalten.
-
Die Regeln zur Codierung in der NAS sind in Kapitel 4 beschrieben.
In der Kombination "fallbezogen" / "mit Historie" ist der Datenumfang in der Sekundärdatenbank grundsätzlich geeignet, selbst zur Abgabe von Ausgaben oder als Quelle für die Fortführung von weiteren Sekundärdatenbeständen genutzt zu werden.
Bei Einführung einer neuen GeoInfoDok-Referenzversion qualifizieren sich im Rahmen der Migration übertragene bzw. gebildete Objekte mit Sterotype und Tagged Value "retired" nicht aufgrund ihres Migrationshintergrundes zur NBA-Abgabe.
5.4.1. Fachliche Anforderungen
Die fachlichen Anforderungen zur Nutzerbezogenen Bestandsdatenaktualisierung (NBA) gründen sich auf die vorhandenen Verfahren, wie sie in ALK/ATKIS und im ALB realisiert vorliegen. Diese Verfahren sind nicht identisch. Weitere fachliche Anforderungen lassen sich folgendermaßen zusammenfassen:
Änderungsdaten sind auf der Grundlage der Fortführungsdaten abzuleiten, die ihrerseits die Struktur der Bestandsdaten aufweisen. Änderungsdaten zur Nutzerbezogenen Bestandsdatenaktualisierung sollen:
-
kontinuierlich und fortführungsfallbezogen (Änderungsdaten) und/oder
-
stichtagsbezogen (Differenzdaten) abgegeben werden können.
Fortführungsfallbezogen bedeutet, dass alle Veränderungen, die in einem zurückliegenden Zeitraum stattgefunden haben, der zeitlichen Reihenfolge nach aufgeführt werden. Damit wird es möglich, alle Prozesse schrittweise im aufnehmenden System nachzuvollziehen. Voraussetzung ist allerdings, dass auch alle Informationen in den Änderungsdaten enthalten sind, die das Erzeugen, Ändern und Löschen von Objekten in dem zurückliegenden Zeitraum betreffen.
Im Gegensatz dazu liefert das stichtagsbezogene Verfahren nur die Differenzdaten, die nötig sind, um den Ausgangszustand beim Nutzer auf den vom Nutzer gewünschten Endzustand zu bringen. Was auf dem Weg zum Endzustand mit den Objekten geschehen ist, kann in diesem Fall nicht nachvollzogen werden. Die stichtagsbezogenen Differenzdaten stellen eine Untermenge der Änderungsdaten dar und können durch Auswertung aus ihnen abgeleitet werden; sie umfassen alle neu entstandenen Objekte, die jeweils aktuellen Versionen von fortgeführten Objekten sowie Angaben zu historisch gewordenen Objekten.
Für jeden Nutzer wird ein Profil angelegt, das beschreibt, nach welchen Kriterien der Nutzer mit Änderungsdaten aus dem einmal für das NBA-Verfahren vorgehaltenen Bestand versorgt werden soll. Dieses Profil ist vor der ersten Datenabgabe zu erstellen.
|
Note
|
Der Benutzungsauftrag 0040 für die erste Datenabgabe enthält eine Profilkennung; diese muss dem System vor der Verarbeitung bekannt sein. |
Für jeden Benutzer wird eine Profilkennung angegeben. Diese Kennung wird auch verwendet, um in der OA AX_NutzerbezogeneBestandsdatenaktualisierung_NBA eine automatische Abarbeitung der NBA-Dateien zu ermöglichen. Mit der Profilkennung kann eindeutig der Bezug zur AX_BenutzergruppeNBA hergestellt werden, welche die maßgeblichen Selektionskriterien des Nutzers enthält. Nutzerbezogene Selektionskriterien sind:
-
Fachlich durch Angabe von Objektarten, Attributarten und -werten sowie Relationen,
-
Räumlich durch Angabe einer Fläche und
-
Zeitlich durch Angabe eines Zeitintervalls.
Objektarten, Attribute und Relationen bestimmen auch den inhaltlichen Umfang der abzugebenden Daten für den einzelnen Nutzer; diese Angaben sind ebenfalls im Nutzerprofil, das z.B. in ALKIS durch die Objektart AX_Benutzergruppe realisiert ist, zu hinterlegen.
5.4.2. Modellierung
Das NBA-Verfahren ist für alle Objektarten anzubieten, die eine datenführende Stelle im Bestand führt, ausgenommen Objekte mit dem Stereotype und dem Tagged Value "retired". Für den Nutzer kann die Selektion auf dem gesamten Vorrat der Objekteigenschaften aufsetzen; die Anforderungen des Datenschutzes sind dabei jedoch zu berücksichtigen. Als Ergebnis liefert das NBA-Verfahren als kleinste Einheiten der Änderungsdaten immer Fachobjekte. Werden Fortführungsdaten für dasselbe Zeitintervall in mehreren Portionen an Nutzer abgegeben, stellt das abgebende System sicher, dass dieselbe Version eines Fachobjektes nur einmal an den Nutzer abgegeben wird.
Diese Daten sind vollständig in Bezug auf das aktuelle Nutzerprofil; aus Sicht des gesamten Datenbestandes können diese Objekte unvollständig sein. Sofern der Nutzer seine Selektion auf einzelne Objekteigenschaften beschränkt (Nutzerprofil), können zwischen den Lieferungen Inkonsistenzen zwischen dem vorhandenen Datenbestand beim Nutzer und der aktuellen Datenhaltung in der datenführenden Stelle auftreten. Dies kann passieren durch die Aktualisierung der Bestandsdaten im Bereich der Selektionskriterien oder Änderungen der Selektionskriterien. Derartige Inkonsistenzen müssen vom aufnehmenden System gehandhabt werden.
Die räumliche Ausdehnung des Interessengebiets eines Nutzers wird durch Angabe beliebiger Flächen (Flächenobjekte) im Nutzerprofil beschrieben. Raumbezogene Elementarobjekte (REO) qualifizieren sich, sobald die Geometrie eines Objekts durch die Geometrie des Interessengebietes angeschnitten wird (Operation INTERSECTS) oder die Geometrie des Objektes vollständig im Interessensgebiet liegt.
Vor der ersten Datenabgabe ist das Nutzerprofil (AX_Benutzergruppe) mit den fachlichen, räumlichen und zeitlichen Kriterien für die NBA-Änderungsdaten zu erstellen. Die fachlichen und räumlichen Kriterien können auch im Nachhinein verändert werden.
Technisch soll die Änderung von Selektionskriterien einer NBA stets durch einen Fortführungsauftrag der Verarbeitungsart 4000 (Fortführen ohne Sperre) abgewickelt werden, der die Objektarten AX_BenutzergruppeNBA und ggf. AX_Benutzer umfasst. Dabei sind Fortführungen während laufenden NBA-Prozessen unzulässig.
Aus Sicht des NBA-Beziehers müssen alle Objekte und mit ihnen in relationalem und attributivem [sprich: schlüsselseitigem] Zusammenhang stehenden weiteren Objekte, die in das Gebiet der Erweiterung ganz oder teilweise fallen, wie bei einer NBA-Erstabgabe behandelt werden. Gleiches gilt auch für fachliche Erweiterungen innerhalb eines NBA-Gebietes. Das heißt, dass die zum bisherigen NBA-Gebiet gehörige Datenabgabe sich um Einfüge-Operationen für die erstmalig abzugebenden Objekte vergrößert. Erweiterungen und Wieder- bzw. Aufholungsläufe schließen sich aus. Für NBA-Bezieher sollen in Zusammenhang mit räumlichen und fachlichen Reduzierungen keine Löschsätze erzeugt werden. Änderungen zu den nicht mehr räumlich bzw. fachlich inbegriffenen Objekten werden ab der Reduzierung einfach nicht mehr geliefert. Zeitliche Erweiterungen (zusätzliche Abgabe von historischen Versionen) und Reduzierungen sind nicht vorgesehen.
In welchem Umfang Objekte durch Nachverfolgung von Relationen nachzuziehen sind, muss ebenfalls in den Selektionskriterien des Nutzerprofils beschrieben sein.
Der Zeitraum, für den die Bereitstellung von Änderungsdaten nach dem Verfahren NBA für verschiedene Nutzer sichergestellt werden muss, kann zeitlich begrenzt werden (zeitlicher Rahmen). Damit wird es möglich,
-
für jeden Nutzer Änderungsdaten rückwirkend innerhalb dieses Zeitraums anzufordern und
-
Änderungsdaten nutzerbezogen abzugeben, sie aber nicht nutzerbezogen vorhalten zu müssen.
Das Verfahren zur Nutzerbezogenen Bestandsdatenaktualisierung erfordert, dass für diesen Zeitraum Informationen über die Veränderung des Datenbestandes vorgehalten werden. Der Zeitraum wird durch die datenführende Stelle in Abstimmung mit den Nutzern bestimmt.
Die beim Verfahren NBA erforderliche Verwaltung der verschiedenen Ausprägungen eines Objektes über die Zeit wird durch das Versionskonzept abgedeckt. Deshalb wird
-
die Datenhaltung der Änderungsdaten auf der Ebene der Bestandsdaten vorgenommen,
-
die Führung der Informationen für das Verfahren der Nutzerbezogenen Bestandsdatenaktualisierung auf das Versionskonzept aufgesetzt und
-
keine neue, zusätzliche und damit redundante Datenstruktur entwickelt.
Damit ist es möglich,
-
aus einer Sammlung von Veränderungen,
-
die jeweils die vollständigen Informationen zu den Objekten des Bestandes enthalten müssen,
-
über den Zeitraum mehrerer Jahre hinweg (in Abhängigkeit vom zeitlichen Rahmen),
-
Auswertungen nach
-
inhaltlichem Umfang durch Objektarten, Attribute und Relationen,
-
räumlicher Ausdehnung durch Flächen und
-
zeitlicher Ausdehnung durch Zeitintervalle sowie
-
-
nutzerbezogen
durchzuführen.
Um eindeutig die zu überschreibende Version zu kennzeichnen und Übermittlungsfehler im NBA-Verfahren aufzudecken, ist es erforderlich, den Objektidentifikator beim Datenaustausch um das Entstehungsdatum/-zeit zu ergänzen. Dies erfordert folgende Regeln:
-
Entstehungsdatum/-zeit im Objektidentifikator kann bei der Implementierung (z.B. im aufnehmenden System) weggelassen werden (Ersatz durch Zeitstempel der Versionen).
-
Beim Datenaustausch mittels NBA-Verfahren mit fortführungsfallbezogener (kontinuierlicher) Datenabgabe wird beim Austausch von Objektversionen die Relation mit einem zum Entstehungsdatum der Objektversion passenden Entstehungsdatum der referenzierten Information ausgegeben.
-
Beim Datenaustausch mittels NBA-Verfahren mit stichtagsbezogener Datenabgabe (Differenzdaten) wird beim Austausch von Objektversionen die Relation mit einem zum Stichtagsdatum passenden Entstehungsdatum der referenzierten Information ausgegeben.
-
Bei der Erzeugung der Austauschdatei für die Nutzerbezogene Bestandsdatenaktualisierung muss das abgebende System folgende Funktionen erfüllen:
-
Selektion der abzugebenden Daten aus dem (ggf. temporären) Historiennachweis entsprechend den im Nutzerprofil hinterlegten Selektionsketten und Filterangaben,
Erzeugung der Fortführungsoperationen für das aufnehmende System aus dem Historiennachweis,
-
Umwandlung der Daten in die Normbasierte Austauschschnittstelle.
-
Für die Ableitung der zu erzeugenden Fortführungsoperationen ist auszuwerten, ob das sich für die Datenausgabe qualifizierende Objekt aus Sicht der Datenhaltung eine erste, weitere oder letzte Version ist.
Bei Verfolgung von inversen Relationen kann <wfs:PropertyName> bzw. <wfsext:PropertyName> mit dem Attribut resolve="local" kein Lebenszeitintervall bei Selektionskriterien für die NBA-Abgabe transportieren. Das hat zur Folge, dass eine oder mehrere Objektversion(en) als Ergebnis geliefert werden. Für die korrekte zeitliche Zuordnung sind weitere Bearbeitungsschritte erforderlich, die durch die Software-Implementierungen sicherzustellen sind.
5.4.2.1. Abgabe von Änderungsdaten
Bei der kontinuierlichen, fortführungsfallbezogenen Datenabgabe (Änderungsdaten) werden alle sich für die Datenabgabe qualifizierenden Versionen eines Objektes verarbeitet. Das betrachtete Zeitintervall erstreckt sich von der letzten Datenabgabe bis maximal zur Gegenwart. Dabei ist aus Sicht der Datenhaltung auszuwerten, ob es sich um eine erste, weitere oder letzte Version eines Objektes handelt.
| sich qualifizierende Version aus Sicht der Bestandsdaten-DB | auszugebende Operation |
|---|---|
erste Version eines neuen Objekts |
<Insert> |
weitere Version eines Objektes |
<Replace> der letzten übermittelten Version (Entstehungsdatum/-zeit angeben) |
letzte Version eines Objektes |
<Delete> der letzten übermittelten Version (Entstehungsdatum/-zeit angeben) |
In dem Fall, dass ein Objekt untergeht ("historisiert" wird), ist bei Sekundärdatenbanken mit vollständigem Historiennachweis statt des <wfs:Delete>-Operators der ansonsten in der NAS nicht unterstützte <wfs:Update>-Operator verwendet (siehe Abschnitt 5.1.5).
5.4.2.2. Abgabe von Differenzdaten
Bei der stichtagsbezogenen Datenabgabe (Differenzdaten) wird unter den Versionen eines Objektes jeweils nur die jüngste oder letzte Version verarbeitet, deren Entstehungs- bzw. Untergangszeit im betrachteten Zeitintervall liegt. Auch hier muss bei Sekundärdatenbanken mit vollständigem Historiennachweis im Fall, dass ein Objekt untergeht ("historisiert" wird), statt des <wfs:Delete>-Operators der ansonsten in der NAS nicht unterstützte <wfs:Update>-Operator verwendet werden (siehe Abschnitt 5.1.5).
| jüngste oder letzte sich qualifizierende Version aus Sicht der Bestandsdaten-DB | auszugebende Operation |
|---|---|
erste Version eines neuen Objektes |
<Insert> der aktuellen Version dieses Objektes |
weitere Version eines Objektes |
<Replace> der letzten übermittelten Version (Entstehungsdatum/-zeit angeben) mit der aktuellen Version dieses Objektes |
letzte Version eines Objektes |
<Delete> der letzten übermittelten Version (Entstehungsdatum/-zeit angeben) |
5.4.3. Portionierung von NBA-Daten, Protokolldatei
Die Portionierung von NBA-Daten ist optional. Es besteht kein Zwang, diese zu verwenden, sie erlaubt jedoch den NBA-Beziehern die Übernahme der Daten in Etappen, was sich in der Vergangenheit bezüglich der Altverfahren insbesondere bei umfangreichen Datenbeständen bewährt hat.
Es werden insbesondere die folgenden Anforderungen adressiert: Bereitstellung der Daten von ALKIS und von ATKIS in geometrischer Portionierung. Die Portionsgröße soll variabel, aber einheitlich für einen Bezieher (Parametrisierung der Portionsgröße im Benutzerprofil) sein. NREO und ZUSO werden portionsbezogen über Relationen gemäß Selektionskriterien im Nutzerprofil nachgezogen. Eine Portionierung allein nach Datenmenge ist nicht ausreichend.
Die Datenabgabe an Sekundärnutzer soll möglichst "vollautomatisch" für das abgebende System und das aufnehmende System sein. Hierfür wird das Attribut <profilkennung> verwendet.
Bei der unportionierten Ausgabe war die Ausgabe der Profilkennung früher nicht verpflichtend. Diese Attributart wurde daher als Pflichtattribut bei AX_NutzerbezogeneBestandsdatenaktualisierungNBA ergänzt. Damit wird nicht zwischen der portionierten und unportionierten Ausgabe durch Weglassen der Attributart <portionskennung> unterschieden, sondern durch die Angaben in <laufendeNummerVonGesamtzahl> und <gesamtzahl> im Datentyp AX_Portionskennung. Im Falle der unportionierten Abgabe sind beide Werte mit "1" belegt.
Portion ohne Raumbezug
Vor der Portionierung müssen über einen Benutzungsauftrag alle Objekte und mit ihnen in relationalem und attributivem Zusammenhang stehenden weiteren Objekte (ZUSO, NREO, REO) über die Selektionskriterien aus der DHK selektiert worden sein. Diese selektierte Menge an Objekten kann dann ggf. portioniert werden, entweder mit Hilfe von geometrischen Parametern oder ohne. Die Portionierung zieht keine weiteren (ggf. fehlende) Objekte nach.
Dazu kann die Attributart AX_Portionskennung.suedwestEcke mit einem der Portionierungskonvention konformen Wert belegt werden oder unbelegt bleiben. Der Dateiname enthält je nachdem den o.g. konformen Wert oder der Dateinamensanteil von suedwestEcke wird nicht belegt. Die Position der nicht-raumbezogenen Portionen in der Portionsfolge ist frei wählbar.
Protokolldatei
Mit einer Portionsfolge bzw. einer unportionierten Gesamtlieferung kann eine optionale Protokolldatei mit Erläuterungen geliefert werden.
|
Note
|
Im Rahmen von massenhaft betriebenen NBA-Verfahren ist es besser, ein Protokoll mit Fehlermeldungen zu erhalten als nicht zu wissen, was mit der NBA-Lieferung schief gelaufen ist. Dass soll nicht heißen, dass fehlerhafte NBA-Daten zur Auslieferung kommen sollen: Man bekommt dann eben nur ein Protokoll ohne Daten. |
Im Falle der Portionierung ist diese als erste Portion einer Portionsfolge mit der laufenden Nummer 0 anzugeben. Im Falle der unportionierten Gesamtlieferung soll der Zusammenhang der Protokolldatei mit der NBA-Lieferung durch deren Dateinamen zum Ausdruck kommen, indem der Name der Protokolldatei gleich dem Namen der NBA-Lieferung ergänzt um "_p" am Ende, gefolgt vom Punkt mit Dateiextension (i.d.R. ".xml", ggf. auch "zip" usw.) sein soll. Ansonsten gelten für die Protokolldatei die Regeln einer Portionsdatei ohne Raumbezug (siehe oben TBD: Genaue Referenz?).
5.4.3.1. Formale Form der Portionierung
Die Abwicklung erfolgt über im automatisierten NBA-Ablauf systemseitig erzeugte AX_NutzerbezogeneBestandsdatenaktualisierung_NBA-Dokumente. Diese werden zu Zeitpunkten gemäß den Vorgaben in AX_BenutzergruppeNBA erzeugt. Die zur jeweiligen Auftragsabwicklung verwendete Anzahl von NBA-Dokumenten bleibt dabei der Implementierung überlassen, allerdings soll es ein zusammenfassendes Auftragsprotokoll zu den ggf. n Ergebnisdateien geben. Aufgrund von [1..n] Benutzungsaufträgen mit Anlass "Nutzerbezogene Bestandsdatenaktualisierung NBA" (0040) werden alle erforderlichen Portionen als eigene unabhängige "Fortführungsaufträge" abgegeben.
|
Note
|
Hier ist der Begriff "Fortführungsauftrag" nicht wortwörtlich im Sinne des AX_Fortfuehrungsauftrag zu verstehen sondern in Form der Response AX_NutzerbezogeneBestandsdatenaktualisierung_NBA, welche die WFS-Operation "Transaction" wie der Fortführungsauftrag enthält. |
Zur redundanzfreien Abgabe von Objekten folgen Erläuterungen bei der Parametrisierung der Portionierung (siehe Abschnitt 5.4.3.2).
Alle Portionen eines Benutzungsauftrages erhalten dieselbe Antragsnummer und dieselbe Auftragsnummer. Bei Folgelieferungen erhöht sich die Auftragsnummer.
Zu jeder Portion sind Metadaten zu erzeugen, aus denen mindestens das geometrische und logische Gebiet der Portion hervorgeht.
5.4.3.2. Anforderungen an das abgebende System
Parametrisierung der Portionierung
Auf Ebene des Nutzerprofils für NBA kann die Portionierung durch Angabe des Portionierungsparameters aktiviert bzw. durch weglassen deaktiviert werden.
Die Selektion und Portionierung erfolgt als zweistufiger Prozess:
-
Die Selektionskriterien in AX_BenutzergruppeNBA dienen zur Auswahl der insgesamt in der Lieferung abzugebenden Objekte (unabhängig davon, ob eine Portionierung erfolgt oder nicht).
-
Die Aufteilung der selektierten Objekte in Portionen erfolgt anhand des Portionierungsparameters wie nachfolgend beschrieben. Bei Einrichtung des NBA-Profils muss auf sinnvolle Parametrisierung der Portionierung geachtet werden.
Fallen in einer Portion keine Fortführungsdaten für die betreffende Lieferung an, so muss diese Portion nicht erzeugt werden. Hierdurch wird die Anzahl der Portionen pro Lieferung variabel, jedoch wird durch die Festlegungen bzgl. Dateinamen klar, welchen Umfang die Gesamtlieferung hat.
Der folgende Portionierungsparameter steht zur Verfügung: Angabe der Seitenlänge in Metern. Sofern gesetzt, handelt es sich um einen positiven, von Null verschiedenen Integer-Wert. Das abgebende System unterteilt automatisch das in den Selektionskriterien insgesamt angegebene Gebiet in entsprechende Quadrate. Dabei gelten die folgenden Regeln:
-
Das Gebiet wird erst von West nach Ost, dann von Süd nach Nord abgearbeitet. Die erste linke untere Ecke ergibt sich dadurch, dass vom südwestlichsten Punkt des Abgabegebietes auf das nächste Koordinatenpaar mit vollen Meterwerten gegangen wird, das südwestlich davon liegt. Ist der südwestlichste Punkt des Abgabegebietes bereits ein Koordinatenpaar auf volle Meterwerte, so wird er direkt verwendet.
-
Alle REOs, die innerhalb eines Portionsquadrates liegen, sowie alle über die Selektionskriterien zusätzlich angeforderten, mit den jeweiligen REOs assoziierten NREO und ZUSO, kommen gemeinsam in eine Portion.
-
Würde ein Objekt aufgrund seiner Ausdehnung in mehreren Portionen auftauchen, so wird es lediglich mit dem in der Reihenfolge am Anfang stehenden Quadrat abgegeben. Ein Beispiel: Ein Flächenobjekt erstreckt sich über Portion (=Quadrat) 12, 13, 21 und 22. Es wird nur in Portion 12 abgegeben.
-
Anhängende NREO und ZUSO werden nur in der jeweils ersten Portion ihres Auftretens abgegeben.
Klammerung der Lieferungsportionen
Die Portionen einer Lieferung werden über geeignete Portionskennungen als zusammengehörig kenntlich gemacht. Diese Kennung ist abzulegen
-
im Attribut AX_NutzerbezogeneBestandsdatenaktualisierung_NBA.portionskennung,
-
im Dateinamen der Portion.
Die Portionskennungen setzen sich wie folgt zusammen:
<NBA-Profilkennung>
<_>
<Datum der NBA-Erzeugung im Format jjjjmmttf>
<_>
<Laufende Nummer der Portion, mit führenden Nullen>
<von>
<Gesamtzahl der Portionen der Lieferung, ohne führende Nullen>
<_>
<Koordinatenpaar der linken unteren Ecke der jeweiligen Portion, durch
Unterstrich getrennt>
|
Note
|
|
Die Attribute 'abgabeintervallBeginn' (Definition: Intervallbeginn der NBA-Abgabe, Kennung: AIB) und 'abgabeintervallEnde' (Definition: Intervallende der NBA-Abgabe, Kennung: AIE) enthalten Angaben über den zeitlichen Geltungsbereich einer NBA-Abgabe. Aus diesen Zeitangaben kann die Reihenfolge der NBA-Lieferungen durch den Empfänger nachvollzogen werden. Die Festlegungen zum Dateinamen bei der Portionierung von NBA-Abgaben sind davon nicht betroffen.
Jede NBA-Portion wird als "lfd.Nr. von Gesamtanzahl", also z.B. "2von8" kenntlich gemacht. Führende Nullen sind zu kodieren, damit nach Dateinamen sortiert werden kann. Dabei gilt: Anzahl der führenden Nullen = Stellenzahl der Gesamtzahl - Stellenzahl der aktuell zu benennenden Portion. Beispiel: 1000 Portionen insgesamt. Aktuell zu benennende Portion ist die vierundneunzigste, daher ergeben sich zwei führenden Nullen: 0094von1000. Gäbe es bei diesem Beispiel als Gesamtanzahl nur 114 Portionen, so ergäbe sich 094von114, also hier nur eine führende Null.
Sinn und Zweck dieser Namenskonvention ist a) die Klammerung der Portionen einer Lieferung und b) es Nutzern zu ermöglichen, Portionen räumlich zuordnen zu können ohne dazu in das NBA-Dokument schauen zu müssen.
Insgesamt ergeben sich Dateinamen z.B. wie folgt:
-
KUNDE_20221026_4von9_3401559_5572720.xml
-
RMR_20080229T141557Z _07von31_3401449_5573000.xml
-
Firmaxy_20040229_004von211_3401559_5572720.xml
-
Firmaxy_20040229_024von211_3401559_5572720.xml
-
Firmaxy_20040229_124von211_3401559_5572720.xml
Erläuterndes Beispiel:
-
In den Selektionskriterien bei der AX_BenutzergruppeNBA steht:
<wfs:Query typeNames="AX_PunktortTA"> <adv:XlinkPropertyPath>istTeilVon/AX_Grenzpunkt</adv:XlinkPropertyPath> <fes:Filter> <fes:BBOX> <fes:ValueReference>position</fes:ValueReference> <gml:Envelope srsName="urn:adv:crs:DE_DHDN_3GK3"> <gml:lowerCorner>353100.000 5532300.000</gml:lowerCorner> <gml:upperCorner>353300.000 5532500.000</gml:upperCorner> </gml:Envelope> </fes:BBOX> </fes:Filter> </wfs:Query> -
In den zusätzlich wirkenden Portionierungsparametern steht:
Seitenlänge = 100m
-
Ergebnis:
Es entstehen maximal vier Portionen, gefüllt mit AX_PunktortTA und zugehörigen AX_Grenzpunkt
Aus Profilkennung und Datum können zur Erhöhung der Übersichtlichkeit geeignete Verzeichnisstrukturen generiert werden.
5.4.3.3. Anforderungen an das aufnehmende System -Verarbeitung der Lieferung
Anhand der Portionskennung ("3von8") wird ausgewertet, ob alle Portionen einer Lieferung übernommen worden sind. Dem aufnehmenden System muss hierzu bekannt sein, aus welchen Portionen die Gesamtlieferung besteht.
Inkonsistenzen müssen so lange "zwischengepuffert" akzeptiert werden, bis die portionierte NBA-Lieferung, also der ganze NBA-Konvoi, komplett übernommen wurde.
Mit vollständiger Übernahme einer portionierten NBA-Lieferung müssen alle "zwischengepufferten" Inkonsistenzen aufgelöst werden können - sollte dies nicht möglich sein, muss eine Fehlermeldung erfolgen und die NBA-Übernahme scheitern.
Erst nach vollständiger Übernahme einer NBA-Lieferung kann diese auf Anforderung quittiert werden und es darf mit der Übernahme der Folgelieferung begonnen werden.
5.4.4. Quittierung von NBA-Lieferungen
Bei Übernahme einer NBA-Lieferung kann eine Quittierung an die liefernde Stelle in Form des NBA-Quittierungs-Auftrags AX_NBAQuittierung erfolgen, soweit dies länderspezifisch gewünscht wird und in der NBA-Lieferung angefordert wurde. Die Art der Verarbeitung der NBA-Quittierung obliegt länderspezifischen Regelungen.
6. AdV-Festlegungen zu Metadaten
Metadaten zu Georessourcen enthalten beschreibende Informationen und treffen damit Aussagen über die Eigenschaften von Datensätzen, Datensatzserien, Geodatendiensten und Anwendungen, deren Struktur und inhaltliche Zusammenhänge. Metadaten sind öffentlich zugängliche Daten und ermöglichen, gezielt Geodaten zu finden und auf diese zuzugreifen. Sie ermöglichen durch ihren informativen Charakter das Vermeiden redundanter Datenerfassung, das Aufdecken vorhandener Lücken in den Datenbeständen, die Standardisierung von Daten und Begriffen, die Qualitätssicherung für die Datensätze, Vergleiche zwischen alternativen Datenbeständen und das Erzeugen von Transparenz des Datenmarktes.
6.1. Metadaten für die europäische Geodateninfrastruktur INSPIRE
Die europäische Kommission hat mit der Richtlinie 2007/2/EG den Aufbau einer europäischen Geodateninfrastruktur für die Gemeinschaftspolitik ("INSPIRE") beschlossen. Ein wesentlicher Bestandteil ist dabei das Auffinden von Georessourcen, d.h. Daten und Diensten mittels Metadaten. Die VERORDNUNG (EG) Nr. 1205/2008 DER KOMMISSION vom 3. Dezember 2008 zur Durchführung der Richtlinie 2007/2/EG des Europäischen Parlaments und des Rates hinsichtlich Metadaten legt für den Aufbau einer Europäischen Geodateninfrastruktur verbindlich eine Struktur und einen definierten Mindestumfang an Metadatenelementen fest, die vollständig auch im AdV-Metadatenprofil berücksichtigt wurden. Metadaten sind ferner datensatzbezogen in den Datenspezifikationen von INSPIRE enthalten. Auch diese sind im AdV-Metadatenprofil enthalten.
6.2. Der Metadatenstandard ISO 19115-1
Der Standard ISO 19115-1 Geographic Information: Metadata bietet ein sehr breites Spektrum zur inhaltlichen Beschreibung von Geodaten. Die Norm enthält mehr als 400 Metadatenelemente, die zur Beschreibung der Geodaten dienen und entweder als verpflichtend (mandatory), bedingt (conditional) oder wahlweise (optional) definiert sind. Um ISO-Konformität zu erreichen, müssen insbesondere alle verpflichtenden Elemente unter Beachtung von konditionalen Zusammenhängen und Kardinalitäten bedient werden. Nutzergruppen können für ihre speziellen Bedürfnisse beliebige Teilmengen (profiles) unter Beachtung der ISO-Konformität definieren. Dabei kann das ISO-Schema auch durch zusätzliche individuelle Elemente (extensions) erweitert werden.
Die ISO 19115-1 in ihrer bisherigen Form berücksichtigt jedoch keine Metadaten zu Diensten. In der ISO 19119 ist ein Kapitel enthalten, das die über die ISO 19115-1 hinausgehenden speziellen Metadaten zur Dokumentation von Diensten auflistet und beschreibt.
6.3. AdV-Metadatenprofil
Die GeoInfoDok referenziert ein Metadatenprofil von ISO 19115-1, in dem sämtliche für die im AAA-Anwendungsschema verwendeten Elemente aufgeführt sind. Dieses deckt sowohl objektbezogene Metadaten (z.B. Qualitätsinformationen bei Punkten) im AAA-Anwendungsschema als auch datenbestandsbezogene Metadaten ab. Das AdV-Metadatenprofil beinhaltet im Wesentlichen eine Tabelle analog zum ISO 19115-Standard mit deutschen Übersetzungen der Begriffe und Definitionen sowie Erläuterungen für deren Anwendung im Kontext der AdV.
Das AdV-Metadatenprofil ist als eigenständiges Dokument veröffentlicht. Auf der Grundlage von ISO 19115 und 19119 wurden dabei die für die AdV relevanten Elemente extrahiert, übersetzt und erläutert und bilden das AdV-Metadatenprofil. Die Übersetzung der Namen und Beschreibungen aus dem Englischen orientiert sich i.d.R. an der Übersetzung durch eine Arbeitsgruppe der GDI-DE. Ein Umstieg des AdV-Metadatenprofils auf die neue ISO 19115-1 wurde geprüft, aber noch nicht umgesetzt.
Darüber hinaus wurden die durch INSPIRE erfolgten Festlegungen und Vorgaben berücksichtigt, d.h. ein Metadatensatz nach AdV-Metadatenprofil ist zugleich INSPIRE-konform.
Der AdV-Metadatenkatalog war bislang Teil der GeoInfoDok, bis einschließlich der Version 6.0.1. Wegen des übergreifenden Charakters der Metadaten (sie gelten nicht nur für AAA-Daten und AAA-Produkte), wird daraus künftig das AdV-Metadatenprofil als Teil der Serie von AdV-Profilen (wie z.B. das AdV-WMS-Profil), losgelöst von der GeoInfoDok-Versionslogik und eigenständig gepflegt und weiterentwickelt. Sämtliche für das AAA-Anwendungsschema notwendigen Elemente sind im AdV-Metadatenprofil enthalten. Die Metadatenelemente werden in der GeoInfoDok in folgenden Kontexten genutzt:
-
Objektbezogene Metadaten, i.d.R. modelliert als integraler Modellbestandteil innerhalb von Attributarten oder als Datentypen innerhalb der Objektarten,
-
Produktbezogene Metadaten, die als Bestandteil der Ausgaben mitgeliefert werden können,
-
Metadaten der AdV im Metadateninformationssystem (AdV-MIS) zur standardisierten Beschreibung der Daten und Dienste der AdV. Dies ist die Gesamtmenge aller AdV-seitig benötigten Metadaten-Elemente einschließlich der INSPIRE-Metadaten.
Produktbezogene Metadaten sind unterteilt in statische und dynamische Metadaten. Statische Metadaten werden i.d.R. einmal vergeben und ändern sich eher selten (z.B. Kontakt zu einem Dienstleistungszentrum). Dabei wird auf das jeweils gültige AdV-Metadatenprofil verwiesen, d.h. diese sind kein integraler Modellbestandteil sondern Bestandteil des AdV-MIS. Gleichwohl können sie über einen Benutzungsauftrag erfragt und an Nutzer abgegeben werden.
Es gibt drei Möglichkeiten für die Führung der produktbezogenen statischen Metadaten:
-
Man führt sie in derselben Datenhaltung wie die Bestandsdaten. Vorteil: Datenhaltung ist autonom, d.h. sie muss bei Produkterstellung nicht auf einen externen Metadaten-Server warten. Handlungsbedarf: Datenhaltung muss zum Metadaten-Server weiterentwickelt werden, sofern eine übergreifende Recherche hierfür erforderlich ist. Zudem muss die Datenhaltung um entsprechende Metadaten-aspekte erweitert werden.
-
Man führt sie in einer zu den AAA-Bestandsdaten externen Datenhaltung (z.B. einem Metadaten-Server). Vorteil: die produktbezogenen statischen Metadaten werden übergreifend recherchierbar. Nachteil: Zwei Datenhaltungssysteme werden in Abhängigkeit zueinander gebracht (Wartezeiten bei Metadatenübermittlung).
-
Kompromiss: Metadaten in externer Datenhaltung und in derselben Datenhaltung wie die Bestandsdaten im Sinne synchroner Bestände (wobei die AdV nicht festlegt, welcher Bestand Primär- und welcher Sekundärbestand ist).
Welche Variante zum Einsatz kommt, hängt von der jeweiligen Implementierung ab.
Produktbezogene Metadaten setzen sich aus modellseitig statischen (strukturiert nach ISO 19139, einschließlich Abfrage, Transport und Pflege per CSW) und dynamischen zusammen. Umfang und Inhalt der an die Nutzer abgegebenen Metadatenelemente werden produktspezifisch von den Facharbeitskreisen der AdV festgelegt.
Dynamische Metadaten: Werden zur Laufzeit erzeugt, wozu aus nicht persistenten Informationen wie z.B. "Zeitpunkt der Ausführung eines Benutzungsauftrages" Metadaten zum Benutzungsergebnis werden.
Diese Dinge müssen aus fachlicher Sicht definiert und gegebenenfalls in das AAA-Anwendungsschema integriert werden. Die Einrichtung und Fortführung von Metadatenbeständen ist daher noch nicht Bestandteil der Modellierung bzw. der Festlegungen.
7. Registry
Gemäß ISO 19135 ist eine Registry ein Informationssystem, in dem ein Register geführt wird. Ein Register wiederum ist eine Zuordnung von sog. Identifiern zu Ressourcen und deren Beschreibungen. Eine Ressource ist in diesem Sinn ein Sachverhalt, der in Abgrenzung zu anderen Sachverhalten eindeutig beschrieben werden kann. Ein Identifier ermöglicht es, Ressourcen der Registry eindeutig zu referenzieren.
Registries nehmen in Geodateninfrastrukturen eine zentrale Rolle ein, da sie das Verwalten, Auffinden und Nutzen von den in der Infrastruktur vorhandenen Geoinformationsressourcen ermöglichen. Dazu gehören beispielsweise Datenprodukte, Dienste, Anwendungsschemata (in UML/XML), Koordinatenreferenzsysteme, Maßeinheiten, Codelisten, Daten- und Objektarten, Dienstetypen oder auch Zeichenvorschriften und Symbole. Die Ressourcen selbst sowie wichtige kennzeichnende Eigenschaften, die für das Verwalten, Auffinden und Nutzen von besonderer Bedeutung sind, werden über eine Registry verfügbar gemacht.
7.1. Registry für Koordinatenreferenzsysteme und Maßeinheiten
Aufgrund der fachlichen Notwendigkeit im Bereich der AdV wird im Auftrag des Arbeitskreis Raumbezug (AK RB) der AdV derzeit ein webbasiertes Register für Koordinatenreferenzsysteme aufgebaut, um aus amtlicher Quelle verlässliche CRS-Beschreibungen bereitzustellen. Die Umsetzung erfolgt durch die Projektgruppen AFIS (AK RB) und GDI-Standards (AK IK) der AdV. Mit dem GDI-DE Modellprojekt Registry erfolgt ein kontinuierlicher Austausch. Die Umsetzung basiert auf den ISO-Normen:
-
ISO 19111 Spatial referencing by coordinates,
-
ISO 19127 Geodetic codes and parameter sowie
-
ISO 19135 Procedures for item registration.
Als Ressourcen für die Umsetzung wurden Ressourcen ausgewählt, die in nahezu jeder NAS-Datei verwendet werden:
-
Koordinatenreferenzsysteme (Abkürzung: CRS) mit den dazugehörigen Bestandteilen wie Koordinatensysteme, Datum, Koordinatenoperationen, usw,
-
Maßeinheiten (Abkürzung: UoM), die auch von den Koordinatenreferenzsystemen verwendet werden.
Eine Web-Schnittstelle stellt für entsprechend berechtigte Stellen eine Benutzeroberfläche als Auskunftssystem mit Suche sowie eine Oberfläche zur Pflege des AdV-CRS-Registers bereit.
Folgende Akteure sieht das AdV-CRS-Register derzeit vor:
| Rolle | Rollenbesetzung |
|---|---|
Register-Owner (Eigentümer der CRS-Registry) |
AdV |
Operationeller Betrieb der Registry |
BKG |
Register-Manager (fachlich verantwortliche Stelle für die tatsächliche Pflege) |
AAA-Revisionsausschuss der AdV |
Control-Body (fachlich verantwortliche Stelle, die über neue Einträge entscheidet) |
PG AFIS des Arbeitskreis Raumbezug der AdV |
Submitting-Organisations (Stelle, die Änderungswünsche übermitteln darf) |
AAA-Revisionsausschuss/BKG/Länder |
Nutzer |
Jeder, öffentlich zugänglich |
Die AdV-Registry für CRS und Maßeinheiten liegt prototypisch vor und soll in Zusammenarbeit mit der Betriebsstelle GDI-DE zu einer zentralen Komponente der Geodateninfrastruktur in Deutschland weiterentwickelt werden. Dementsprechend könnten sich die aufgelisteten Rollen noch ändern.
Ein Registry-Dienst soll zunächst nicht zur Anwendung kommen. Nach derzeitiger Beschlusslage in der AdV ist derzeit noch nicht beabsichtigt, die CRS-Liste dieses Dokuments durch die CRS-Registry zu ersetzen. Insofern hat die GeoInfoDok weiterhin normativen Charakter in Bezug auf die CRS in Deutschland.
7.2. Registry für Codelisten
Häufig verwendete oder nach einem vorgegebenen Konzept zu beschreibende Eigenschaften von Geoobjekten werden im AAA-Datenmodell häufig durch Codes abgebildet. Die Menge der möglichen Werte ist in der Regel in einer Codeliste aufgeführt. Die Codeliste wird meist gemeinsam mit dem Datenmodell veröffentlicht. Datenerfassern muss diese Codeliste, die Bedeutung der einzelnen Codes, der Pflege- und Qualitätszustand bekannt sein, um für die Erfassung den passenden Wert auswählen zu können.
Teilweise sind die in einer Codeliste verfügbaren Codes allerdings nicht ausreichend. Im AdV-Modell wird mitunter nur die gemeinsame Sicht abgedeckt, aber nicht die länderspezifischen Bedürfnisse. In diesem Fall ist von der AdV vorgesehen, dass bestimmte Codelisten auch länderspezifisch erweitert werden können. Um die Vergabe von gleichen Codes und damit inkonsistente Datenbestände zu verhindern, ist es notwendig, die Pflege der länderspezifischen Codelisten (z.B. Modellarten) zu organisieren. Eine Registry ist hierfür ein geeignetes Werkzeug, das es ermöglicht, die Pflege von nationalen und länderspezifischen Codelisten sowie auch anderen Codelisten zu organisieren.
Der Einsatz eines Registers für Codelisten unterstützt:
-
die zuständigen Stellen bei der Pflege der Codelisten und der Codes,
-
die Datenerfasser bei der Auswahl geeigneter Codes und Erstellung von harmonisierten Geodatensätzen und
-
die Anwender bei der Interpretation der Codes in einem Datensatz.
Eine Registry kann verschiedene Ressourcen enthalten. Sind die Ressourcen die Codelisten des AAA-Anwendungsschemas, wird der Begriff einer Code-Listen- und Enumerations-Registry verwendet. Abgekürzt wird dieser Begriff mit CER. Zunächst werden Definitionen und Regelungen von ISO und AdV zu der Thematik dargestellt, dann folgt das eigentliche CER-Konzept.
7.2.1. Definitionen und Regelungen zu Code-Listen und Enumerationen
Eine Codeliste definiert einen Wertebereich, in dem für jeden zulässigen Wert ein Code zugeordnet wird (ISO 19136). Die Abgrenzung der Begriffe "Enumeration" und "CodeList" erfolgt gemäß ISO 19103:
Eine Enumeration ist eine abschließende Sammlung von zulässigen Werten mit dem Stereotyp «enumeration» versehen. Enumerationen können nicht erweitert werden.
Eine Codelist ist eine nicht abschließende Sammlung von zulässigen Werten mit dem Stereotyp «codeList» versehen. Codelisten können erweitert werden.
ISO 19103 unterscheidet zwei Arten von Codelisten: Solche mit dem Tagged Value "codeList" (diese werden von einer einzigen zuständigen Stelle geführt) und solche ohne diesen Tagged Value (diese können beliebig von jedem Benutzer des zugehörigen Anwendungsschemas erweitert werden).
Im Basisschema gebrauchte Code-Listen, die von ihrem Charakter her a) von den anwendungsspezifischen Subschemata gefüllt werden müssen und b) zur Integration unterschiedlicher Anwendungen erweiterbar sein müssen, werden im Basisschema in der Regel als leere Klassen definiert und mit dem Stereotype «CodeList» versehen. In einigen Fällen sind bei Codelisten im Basisschema Wertearten angegeben (z.B. bei AA_Anlassart). Erweiterungen und Änderungen dieser Listen führen nicht zu einer neuen Version der Austauschschnittstelle. Sie erscheinen demnach nicht im Ausgabe-Schema, sondern werden in Form eines dictionaries in einer "externen" XML-Datei geführt. Sie werden an zentraler Stelle mit der Möglichkeit des online-Zugriffs geführt und gepflegt. Mit den Implementierungen des AAA-Modells wächst der Bedarf für ein Konzept zur Erweiterung dieser Codelisten. Hat sich z.B. Land XYZ im Sinne des AdV-Leitfadens zur Fachdatenanbindung eine länderspezifische Ausgabe geschaffen, so fehlt noch ein Code in der Codelist AX_Anlassart_Benutzungsauftrag, um die Erzeugung eben dieser Ausgabe initiieren zu können.
Alle Codelisten des AAA-Fachschemas führen vier- oder sechsstellige Ganzzahl-Codes (wegen führenden Nullen ungleich Integer). Für eine länderspezifische Erweiterung kommen folgende Codelisten mit folgender Stellenzahl in Frage:
| Codelist | Stellenzahl |
|---|---|
AA_Anlassart |
6 |
AA_Anlassart_Benutzungsauftrag |
4 |
AA_WeitereModellart |
unbegrenzt |
Die länderspezifische Erweiterung von Codelisten des AAA-Fachschemas (hier speziell der Codes) wird mit dem zweistelligen Länderkürzel (vgl. Abschnitt 3.3.9, “Identifikatoren, Verknüpfungen”) eingeleitet. Dem BKG steht das dort vorgesehene dreistellige Kürzel "BKG" zur Verfügung.
Als weitere Zeichen sind die Ziffern {0-9} und Zeichen {A-Z, a-z, ohne Umlaute} zulässig. Groß- und Kleinschreibung wird unterschieden.
Die Stellenanzahl des länderspezifischen Codes einschließlich Präfix sollte zur Erleichterung der Implementierung mit der des AdV-Codes identisch sein. Zukünftig könnte bei Fachinformationssystemen ggf. Bedarf an einer größeren Stellenzahl bestehen.
Beispiele:
-
Ein länderspezifischer vierstelliger Benutzungsanlass z.B. lautet "RP10" oder auch "RPA6".
-
Ein vierstelliger Benutzungsanlass des BKG (einzige Instanz dreistelligen Kürzels) lautet "BKG7" oder auch "BKGa".
Hierdurch vereinfacht sich eine zentrale Registrierung ("Registry") der erweiterbaren Codelisten (jedes Land und das BKG arbeitet im eigenen Namensraum). Falls die erwähnte Registrierung im Rahmen von GDI-DE nicht benötigt wird, kann sie sogar komplett entfallen.
Die Codelisten- und Enumerationswertearten mit Stereotype und Tagged Value "retired" führen diesen Status mit den zugehörigen Informationen ("gueltigVonModellversion", "gueltigBisModellversion") auch in der CER.
Eine weitere Anforderung zur Führung einer CER ergibt sich aus Abschnitt 3.6, “Qualitäts- und Metadaten”:
"In der Rollenangabe ist ein Codelistenverweis erforderlich, der gemäß ISO/TS 19139 8.5.5 eine URL sein muss. Im Beispiel ist eine URL auf ein Code-List-Dictionary im OGC-Schemarepository angegeben. Dies kann alternativ - wie bei Schemaverweisen - auch ein anderer gültiger Verweis auf ein Code-List-Dictionary sein."
Dies wird mit einem Beispiel näher illustriert:
<gmd:role>
<gmd:CI_RoleCode codeList="http://schemas.opengis.net/iso/19139/20070417/resources/Codelist/gmxCodelists.xml#CI_RoleCode" codeListValue="processor">processor</CI_RoleCode>
</gmd:role>"
7.2.2. Registry für Codelisten und Enumerationen
Codelisten und Enumerationen der AdV werden in dem Codelisten-Register der GDI geführt (Link: GDI-DE Registry). Dies betrifft derzeit die Codelisten und Enumerationen aus dem AAA-Anwendungsschema und den Anwendungsschemata Landbedeckung, Landnutzung, Geometrische Verbesserung und Bodenrichtwertmodell. Die Vorgehensweise ist hierbei wie folgt:
-
Die Codelisten und Enumerationen werden unter dem Namespace
https://registry.gdi-de.org/codelist/de.adv-online.gid geführt. -
Die URL zum Aufruf der Codelisten und Enumerationen lautet:
https://registry.gdi-de.org/codelist/de.adv-online.gid/{Codelist-Name}/{Werteart} -
Codelisten und Enumerationen der Anwendungsschemata in der GeoInfoDok werden im UML-Modell vom Revisionsausschuss gepflegt.
-
Veröffentlicht werden zunächst die Codelisten und später auch die Enumerationen der aktuellen Version.
7.3. XML-Schema-Register
XML-Schemata werden bei OGC und INSPIRE in einfachen, dateibasierten Repositories über WebServer bereitgestellt. Diese einfache Bereitstellung ist für die Zwecke der AdV ausreichend. Hier wird kein nach ISO-19135 ausgerichtetes Register benötigt, sondern eine einfache Lösung reicht aus. Da GDI-DE bereits ein entsprechendes Register aufgebaut hat, wurden sämtliche NAS-Dateien dort eingestellt. Siehe http://repository.gdi-de.org/schemas/adv.
7.4. Enterprise Architect Subversion-Server
Das AAA-Anwendungsschema wird seit der Umstellung auf das Modellierungstool Enterprise Architect nicht mehr lokal auf den Rechnern der Mitglieder des AAA-Revisionsausschusses geführt, sondern zentral in einem UML-Schema-Repository auf einem Server. Damit gilt dies als ein weiteres zentral geführtes Register der AdV. Der Vorteil ist eine eindeutige Referenzversion und die Vermeidung von Versionskonflikten durch ein klares Versionskonzept sowie eine zugangsbeschränkte Nutzung. Zudem werden sämtliche Änderungen aller Akteure dokumentiert.
Es besteht neben der Veröffentlichung in AdV-online die Möglichkeit, für weitere Personen (z.B. den AAA-Ansprechpartnern der Länder) lesenden Zugriff einzurichten.
Auch die Einbindung der ISO-Datenmodelle erfolgt über einen Subversion-Server der EU, der beim Joint Research Center (JRC) gehostet wird.
8. Koordinatenreferenzsysteme und Maßeinheiten
8.1. Koordinatenreferenzsysteme für AFIS-ALKIS-ATKIS
8.1.1. Verwendete Systematik
In AFIS-ALKIS-ATKIS kann für jede Geometrie das zugehörige Koordinatenreferenzsystem (CRS) angegeben bzw. gespeichert werden. In diesem Abschnitt werden die dafür verwendeten (Kurz-) Bezeichnungen definiert.
Die Kurzbezeichnung setzt sich aus den folgenden Informationen zusammen:
{Land}_{geodätisches Datum}_{Koordinatensystem}_{Submerkmale des Koordinatenreferenzsystems (z.B.Lagestatus)}
Die zu benutzenden Kurzbezeichnungen werden in den weiter unten folgenden Tabellen festgelegt.
8.1.2. Koordinatenreferenzsysteme für 2D-Lageangaben
Vorbemerkungen:
-
Die Koordinatenwerte der CRS werden in folgender Reihenfolge angegeben:
-
bei Gauß-Krüger-Abbildung: Rechtswert, Hochwert,
-
bei UTM-Abbildung: East, North,
-
bei Lambertscher Kegelabbildung: East, North sowie
-
bei ellipsoidischen (geodätischen) Koordinaten: Breite, Länge.
-
-
Die Platzhalter <sn> und <zn> sind jeweils durch die Nummer des Streifens (bei Gauß-Krüger) bzw. der Zone (bei UTM, ohne Buchstabenkennung) zu ersetzen. Es wird also für jeden Streifen bzw. jede Zone ein eigenes CRS definiert. In dem Register sind die Parameter "false easting" mit dem Wert 500000 m und "zone number" mit dem Wert der jeweiligen Zone bzw. des Streifens zu belegen.
Beispiel:
DE_DHDN_3GK2 (Rechtswert, Hochwert): 581996.560 5616134.450
ETRS89_UTM32 (East, North): 369949.671 5615301.383
-
Zur Vereinfachung von Auswertungen (z. B. Koordinatenlisten) beinhalten die Koordinatenangaben bei der Präsentation der Standardausgaben trotzdem die Streifen- bzw. Zonenkennung, z.B.:
GK-Koordinaten (Rechtswert, Hochwert): 2581996.560 5616134.450
UTM-Koordinaten (East, North): 32369949.671 5615301.383
| Hauptgruppe | Untergruppe | Land | Kurzbezeichnung |
|---|---|---|---|
DHDN, Lambert Konforme Kegelabbildung |
DE |
DE_DHDN_Lam |
|
DHDN, ellipsoidische (geodätische) Koordinaten |
DE |
DE_DHDN_Lat-Lon |
|
DHDN, Gauß-Krüger-3-Grad-Streifen |
DE |
DE_DHDN_3GK<sn> |
|
altes Lagefestpunktfeld (Reichsdreiecksnetz) |
DE |
DE_DHDN_3GK<sn>_RDN |
|
BY |
DE_DHDN_3GK<sn>_BY120 |
||
BE |
DE_DHDN_3GK<sn>_BE200 |
||
HH |
DE_DHDN_3GK<sn>_HH100 |
||
HE |
DE_DHDN_3GK<sn>_HE120 |
||
NI |
DE_DHDN_3GK<sn>_NI200 |
||
NW |
DE_DHDN_3GK<sn>_NW101 |
||
RP |
DE_DHDN_3GK<sn>_RP101 |
||
SH |
DE_DHDN_3GK<sn>_SH200 |
||
TH |
DE_DHDN_3GK<sn>_TH200 |
||
SL |
DE_DHDN_3GK<sn>_SL159 |
||
landesweit vollständig erneuerte Systeme |
|||
BW |
DE_DHDN_3GK<sn>_BW100 |
||
HB |
DE_DHDN_3GK<sn>_HB100 |
||
NI |
DE_DHDN_3GK<sn>_NI000 |
||
NI, ST |
DE_DHDN_3GK<sn>_NI100 |
||
NW |
DE_DHDN_3GK<sn>_NW177 |
||
RP |
DE_DHDN_3GK<sn>_RP180 |
||
HE |
DE_DHDN_3GK<sn>_HE100 |
||
SL |
DE_DHDN_3GK<sn>_SL197 |
||
partiell erneuerte Systeme |
|||
BY |
DE_DHDN_3GK<sn>_BY110 |
||
HB |
DE_DHDN_3GK<sn>_HB110 |
||
HE |
DE_DHDN_3GK<sn>_HE110 |
||
SH |
DE_DHDN_3GK<sn>_SH210 |
||
NI |
DE_DHDN_3GK<sn>_NI210 |
||
NW |
DE_DHDN_3GK<sn>_NW119 |
||
NW |
DE_DHDN_3GK<sn>_NW131 |
||
NW |
DE_DHDN_3GK<sn>_NW133 |
||
NW |
DE_DHDN_3GK<sn>_NW158 |
||
NW |
DE_DHDN_3GK<sn>_NW163 |
||
NW |
DE_DHDN_3GK<sn>_NW166 |
||
NW |
DE_DHDN_3GK<sn>_NW173 |
||
NW |
DE_DHDN_3GK<sn>_NW174 |
||
NW |
DE_DHDN_3GK<sn>_NW175 |
||
NW |
DE_DHDN_3GK<sn>_NW176 |
||
System 40/83, GK-3-Grad |
BB, ST, MV, SN,TH |
DE_40-83_3GK<sn> |
|
System 42/63, GK-6-Grad |
BB, ST, MV, SN,TH, Osteuropa |
DE_42-63_6GK<sn> |
|
System 42/83, GK-6-Grad |
BB, ST, MV, SN,TH, Osteuropa |
DE_42-83_6GK<sn> |
|
System 42/83, GK-3-Grad |
BB, ST, MV, SN,TH, Osteuropa |
DE_42-83_3GK<sn> |
|
System 42/86, GK-3-Grad |
BB, ST, MV, SN,TH, Osteuropa |
DE_42-86_3GK<sn> |
|
System 42/83, ellipsoidische (geodätische) Koordinaten |
BB, ST, MV, SN,TH, Osteuropa |
DE_42-83_Lat-Lon |
|
RD/83, GK-3-Grad |
SN, BB, ST, MV |
DE_RD-83_3GK<sn> |
|
RD/83, ellipsoidische (geodätische) Koordinaten |
SN, BB, ST, MV |
DE_RD-83_Lat-Lon |
|
PD/83, GK-3-Grad |
TH |
DE_PD-83_3GK<sn> |
|
PD/83, ellipsoidische (geodätische) Koordinaten |
TH |
DE_PD-83_Lat-Lon |
|
Katastersysteme der preußischen Landesaufnahme |
|||
System Baden |
BW |
DE_Soldner-Baden |
|
System Württemberg |
BW |
DE_Soldner-Wuerttemberg |
|
System Berlin |
BE |
DE_Soldner-Berlin |
|
System 18 Müggelberg |
BE |
DE_Soldner-Mueggelberg |
|
System 17 Greifswald |
MV |
DE_Soldner-Greifswald |
|
System 24 Ostenfeld |
SH |
DE_Soldner-Ostenfeld |
|
System 25 Rathkrügen |
SH |
DE_Soldner-Rathkruegen |
|
System 26 Bungsberg |
MV, SH |
DE_Soldner-Bungsberg |
|
Soldner Grossenhain1 |
SN |
DE_Soldner-Grossenhain1 |
|
Soldner Grossenhain2 |
SN |
DE_Soldner-Grossenhain2 |
|
Soldner Grossenhain3 |
SN |
DE_Soldner-Grossenhain3 |
|
Soldner Leipzig |
SN |
DE_Soldner-Leipzig |
|
Soldner Torgau |
SN |
DE_Soldner-Torgau |
|
Mecklenburgisches Koordinatensystem 1912 |
MV |
DE_Mecklenburg_1912 |
|
System Hamburg alt |
HH |
DE_Hamburg_220 |
|
System Hamburg neu |
HH |
DE_Hamburg_210 |
|
System ED50/UTM |
Europa |
ED50_UTM<zn> |
|
System ED50, ellipsoidische (geodätische) Koordinaten |
Europa |
ED50_Lat-Lon |
|
System ED87/UTM |
Europa |
ED87_UTM<zn> |
|
ETRS89/UTM |
Europa |
ETRS89_UTM<zn> |
|
ETRS89/GK-3-Grad |
Europa |
ETRS89_3GK<sn> |
|
ETRS89, ellipsoidische (geodätische) Koordinaten |
Europa |
ETRS89_Lat-Lon |
|
ETRS89, Lambert Konforme Kegelabbildung |
Europa |
ETRS89_LCC |
|
ETRS89, Lambert Konforme Kegelabbildung |
DE |
ETRS89_Lam |
|
ETRS89, Lambert Azimuthal, Equal Area |
Europa |
ETRS89_LAEA |
|
WGS84, ellipsoidische (geodätische) Koordinaten |
Welt |
WGS84_Lat-Lon |
|
WGS84/UTM |
Welt |
WGS84_UTM<zn> |
|
WGS84 Lambert Konforme Kegelabbildung |
Europa |
WGS84_LCC |
|
Örtliches oder lokales System |
LOKAL_<Bezeichnung> |
||
CRS unbekannt oder "Dummy-CRS" |
NONE |
8.1.3. Koordinatenreferenzsysteme für 3D-Positionsangaben
| Hauptgruppe | Untergruppe | Land | Kurzbezeichnung |
|---|---|---|---|
DHDN, ellipsoidische (geodätische) Koordinaten incl. ellipsoidische Höhe |
DE |
DE_DHDN_Lat-Lon-h |
|
System 42/83, ellipsoidische (geodätische) Koordinaten incl. ellipsoidische Höhe |
SN |
DE_42-83_Lat-Lon-h |
|
ETRS89, ellipsoidische (geodätische) Koordinaten incl. ellipsoidische Höhe |
Europa |
ETRS89_Lat-Lon-h |
|
ETRS89/UTM incl. ellipsoidische Höhe |
Europa |
ETRS89_UTM<zn>-h |
|
ETRS89/GK-3-Grad incl. ellipsoidische Höhe |
Europa |
ETRS89_3GK<sn>-h |
|
ETRS89, räumliche kartesische Koordinaten |
Europa |
ETRS89_X-Y-Z |
|
WGS84, räumliche kartesische Koordinaten |
Welt |
WGS84_X-Y-Z |
|
WGS84, ellipsoidische (geodätische) Koordinaten incl. ellipsoidische Höhe |
Welt |
WGS84_Lat-Lon-h |
|
WGS84/UTM incl. ellipsoidische Höhe |
Welt |
WGS84_UTM<zn>-h |
In der Regel finden 3D-CRS nur in 3D-Objektarten, die im Modell mit dem Zusatz 3D gekennzeichnet sind (wie z.B. AX_Bauteil3D), Verwendung. In Ausnahmen können auch 2D-CRS bei den 3D-Objektarten genutzt werden. Solche Ausnahmen werden in den Definitionen vermerkt.
Bei Objekten der Objektart "Punktort_TA" und "Punktort_AG" sind in ALKIS 3D-Koordinatenreferenzsysteme nicht zugelassen.
8.1.4. Koordinatenreferenzsysteme für Höhenangaben
| Hauptgruppe | Untergruppe | Land | Kurzbezeichnung |
|---|---|---|---|
Alte Systeme bzw. Bezugspegel |
|||
Alt-Hamburger Null, Hauptflutmesser zu Hamburg 1841 |
HH |
DE_ALT_HH_1841 |
|
Neu-Hamburger Null, Hauptflutmesser zu Hamburg 1872 |
HH, SH |
DE_NEU_HH_1872 |
|
Mittelwasser der Ostsee 1840 bei Swinemünde |
MV |
DE_MWO_1840 |
|
Mittelwasser der Ostsee 1875 bei Swinemünde |
SN |
DE_MWO_1875 |
|
Nullpunkt zu Neufahrwasser bei Danzig |
Bereich Ostsee |
DE_ALT_NWD |
|
Cuxhavener Null am Hauptflutmesser |
NI |
DE_ALT_CUX |
|
Harburger Flutmessernullpunkt bis 1937 |
HH |
DE_ALT_FMN |
|
Helgoländer Null (H.N.) |
SH |
DE_ALT_HELG |
|
Amsterdams Peil (AP) 1818 |
Europa |
EU_ALT_AP |
|
Normaal Amsterdams Peil (NAP) ab 1891 |
Europa |
EU_NAP |
|
Altes bzw. vorläufiges System, NN-Höhe über NHP 1879 |
|||
Altes System, NN-Höhe über NHP 1879, ohne Nivellementreduktion |
DE |
DE_ALT_NN |
|
Altes System in Baden, NN-Höhe über NHP 1879, ohne Nivellementreduktion |
BW |
DE_ALT_NN_BW010 |
|
Altes System in Württemberg, NN-Höhe über NHP 1879, ohne Nivellementreduktion |
BW |
DE_ALT_NN_BW020 |
|
Vorläufiges System, NN-Höhe über NHP 1879, normalorthometrische Höhe |
BY |
DE_VORL_NOH_BY901 |
|
DHHN12 (früher: "Neues System"), NN-Höhen über NHP 1912, Netzteile I bis VIII |
|||
DHHN12, Normalorthometrische Höhe |
DE |
DE_DHHN12_NOH |
|
landesweit vollständig erneuerte Systeme |
|||
DHHN12, Horizont 55, Normalorthometrische Höhe |
NI |
DE_DHHN12_NI120 |
|
DHHN12, Horizont 71, Normalorthometrische Höhe |
BW |
DE_DHHN12_BW130 |
|
DHHN12, System 68-74, Normalorthometrische Höhe |
RP |
DE_DHHN12_RP120 |
|
NKN |
Nordseeküstennivellement (NKN) I (1928 - 1931), Normalorthometrische Höhe |
HB, HH, NI und SH |
DE_ NKN-I_NOH |
Nordseeküstennivellement (NKN) II (1949 - 1955), Normalorthometrische Höhe |
HB, HH, NI und SH |
DE_ NKN-II_NOH |
|
DHHN12, Nordwesteuropäisches Flachlandnivellement (NWELL) (1949 - 1956), Normalorthometrische Höhe |
NI |
DE_DHHN12_NOH_NWELL |
|
DHHN12, Nordwesteuropäisches Flachlandnivellement (NWELL) (1949 - 1956), Geopotentielle Kote |
NI |
DE_DHHN12_CP_NWELL |
|
OKN |
Vorläufiges System, Ostseeküstennivellement, (OKN) I (1896 - 1901), Normalorthometrische Höhe |
DE |
DE_OKN-I_NOH |
Nivellementnetz 1960 |
|||
Nivellementnetz 1960, Normalorthometrische Höhe |
DE |
DE_NIV60_NOH |
|
Nivellementnetz 1960, Horizont 74, Normalorthometrische Höhe |
HB, NI |
DE_NIV60_NOH_NI130 |
|
Nivellementnetz 1960, Horizont 77, Normalorthometrische Höhe |
HB, NI |
DE_NIV60_NOH_HB131 |
|
Nivellementnetz 1960, Geopotentielle Kote |
DE |
DE_NIV60_CP |
|
DHHN85 |
|||
DHHN85, Normal-orthometrische Höhe, Datumspunkt Wallenhorst, Unterirdische Festlegung I |
DE |
DE_DHHN85_NOH |
|
DHHN85, Geopotentielle Kote, Datumspunkt Wallenhorst Kirche, Höhenmarke |
DE |
DE_DHHN85_CP |
|
DHHN92 |
|||
DHHN92, Normalhöhe |
DE |
DE_DHHN92_NH |
|
DHHN92, Geopotentielle Kote |
DE |
DE_DHHN92_CP |
|
DHHN2016 |
DHHN2016, Normalhöhe |
DE |
DE_DHHN2016_NH |
DHHN2016, Geopotentielle Kote |
DE |
DE_DHHN2016_CP |
|
DHHN2016, Normalorthometrische Höhe |
DE |
DE_DHHN2016_NOH |
|
SNN56 |
|||
SNN56, Normalhöhe |
BB, ST, MV, SN,TH |
DE_SNN56_NH |
|
SNN56, Normalorthometrische Höhe |
BB, ST, MV, SN,TH |
DE_SNN56_NOH |
|
SNN76 |
|||
SNN76, Normalhöhe |
BB, ST, MV, SN,TH |
DE_SNN76_NH |
|
SNN76, Normalorthometrische Höhe |
ST |
DE_SNN76_NOH |
|
SNN76, Geopotentielle Kote |
BB, ST, MV, SN,TH |
DE_SNN76_CP |
|
DHDN, Ellipsoidische Höhe |
DE |
DE_DHDN_h |
|
Heitz-Geoid |
NI |
DE_Bessel_h_NI700 |
|
Lelgemann-Geoid |
NI |
DE_Bessel_h_NI710 |
|
United European Levelling Network (UELN) 73/86 |
|||
UELN73/86, Normalhöhe |
Europa |
UELN73-86_NH |
|
UELN73/86, Geopotentielle Kote |
Europa |
UELN73-86_CP |
|
European Vertical Reference System (EVRS) 2000, United European Levelling Network (UELN) 95/98 |
|||
UELN95/98 (EVRF2000), Normalhöhe |
Europa |
EVRF2000_NH |
|
UELN95/98 (EVRF2000), Geopotentielle Kote |
Europa |
EVRF2000_ CP |
|
European Vertical Reference System (EVRS) 2007, United European Levelling Network |
|||
EVRF2007, Normalhöhe |
Europa |
EVRF2007_NH |
|
EVRF2007, Geopotentielle Kote |
Europa |
EVRF2007_CP |
|
WGS84, Ellipsoidische Höhe |
Welt |
WGS84_h |
|
ETRS89, Ellipsoidische Höhe |
Europa |
ETRS89_h |
|
System 42/83, Ellipsoidische Höhe |
SN |
DE_42-83_h |
|
Höhenanomalie (Quasigeoidhöhe) |
|||
EGG97 |
Europa |
EGG97_QGH |
|
GCG2005 |
DE |
DE_AdV_GCG2005_QGH |
|
GCG2011 |
DE |
DE_AdV_GCG2011_QGH |
|
GCG2016 |
DE |
DE_AdV_GCG2016_QGH |
8.1.5. Kombinationen von Koordinatenreferenzsysteme für Lage und Höhe
Kombinationen von Lage- und Höhenbezugsystemen (Compound coordinate reference system, CCRS) werden immer durch Zusammensetzung der Kennungen der Bestandteile unter Verwendung eines "*"-Zeichens zitiert, z.B.
DE_DHDN_3GK2_RDN*DE_DHHN92_NH
Bei Objekten der Objektart "Punktort" sind in AFIS-ALKIS-ATKIS gemäß der Definition der Objektart Punktort zusammengesetzte Koordinatenreferenzsysteme nicht zugelassen.
8.1.6. Angabe des Koordinatenreferenzsystems in der NAS
Die Angabe des CRS in der NAS (GML) hat den Datentypen "anyURI". Damit sind sowohl URL- als auch URN-Angaben erlaubt. Die URL-Variante setzt eine explizite XML-Beschreibung der verwendeten CRS in einer Datei voraus. Da diese noch nicht vorliegt, werden die CRS bis auf weiteres über einen URN wie folgt referenziert:
srsName="urn:adv:crs:{Kurzbezeichnung}"
Bei der Kombination von Koordinatenreferenzsystemen (siehe Abschnitt 8.1.5) genügt es den Namensraum einmal zu Beginn der zusammengesetzten Kennung der CRS anzugeben.
Sobald die entsprechende Beschreibung der CRS vorliegt, können alternativ URL verwendet werden, so dass die CRS wie folgt referenziert werden:
srsName="http://www.adv-online.de/crs/crs.xml#{Kurzbezeichnung}".
Die Koordinatenangaben für Gauß-Krüger- und UTM-Koordinaten beinhalten in der NAS keine Streifen- bzw. Zonenangabe, also z. B.
Gauß-Krüger-Koordinaten (Rechtswert, Hochwert): |
581996.560 5616134.450 |
UTM-Koordinaten (East, North): |
369949.671 5615301.383 |
In der NAS sieht dies dann beispielhaft folgendermaßen aus:
<!-- ... -->
<gml:Point srsName="urn:adv:crs: DE_DHDN_3GK2_NW177">
<gml:coordinates>581996.560 5616134.450</gml:coordinates>
</gml:Point>
<gml:Point srsName=" http://www.adv-online.de/crs/crs.xml#DE_DHDN_3GK2_NW177">
<gml:coordinates>581996.560 5616134.450</gml:coordinates>
</gml:Point>
<!-- ... -->
bzw.
<!-- ... -->
<gml:Point srsName=" urn:adv:crs: ETRS89_UTM32">
<gml:coordinates>369949.671 5615301.383</gml:coordinates>
</gml:Point>
<gml:Point srsName="http://www.adv-online.de/crs/crs.xml# ETRS89_UTM32">
<gml:coordinates>369949.671 5615301.383</gml:coordinates>
</gml:Point>
<!-- ... -->
8.2. Maßeinheiten für AFIS-ALKIS-ATKIS
8.2.1. Verwendete Systematik
In AFIS-ALKIS-ATKIS muss für jeden quantitativen Wert dessen Maßeinheit angegeben sein. In diesem Dokument werden die dafür zu verwendenden Kurzbezeichnungen definiert.
Sollte zukünftig durch ISO, das Open Geospatial Consortium (OGC) oder eine andere Stelle ein entsprechendes Register von Maßeinheiten mit Kurzbezeichnungen geführt werden, so ist vorgesehen, die Bezeichnungen auf die dort definierten Einträge umzustellen.
8.2.2. Kurzbezeichnungen
| Maßeinheit | Kurzbezeichnung |
|---|---|
Meter |
m |
Millimeter |
mm |
Kilometer |
km |
Quadratmeter |
m2 |
Kubikmeter |
m3 |
Grad, dezimal (Altgrad) |
grad |
Gon, dezimal |
gon |
Radians |
rad |
m/s2 (m*s^-2) |
ms-2 |
m2/s2 (m2*s-2) |
m2s-2 |
m/s2/m (m*s-2*m-1) |
s-2 |
Kilovolt |
kV |
Die in Klammern angegebenen Maßeinheiten werden in den Standardausgaben und Dokumentationen verwendet. |
8.2.3. Angabe der Maßeinheit in der NAS
Die Angabe der Maßeinheit (Unit of Measure) in der NAS (GML) hat den Datentypen "anyURI". Damit sind sowohl URL- als auch URN-Angaben erlaubt. Die URL-Variante setzt eine explizite XML-Beschreibung der verwendeten Maßeinheit in einem GML-dictionary voraus. Da ein solches im Augenblick nicht vorliegt, werden die Maßeinheiten bis auf weiteres über einen URN wie folgt referenziert:
uom="urn:adv:uom:{Kurzbezeichnung}"
Sobald die entsprechende Beschreibung der Maßeinheiten vorliegt, können alternativ URL verwendet werden, so dass die Maßeinheiten wie folgt referenziert werden:
uom="http://www.adv-online.de/uom/uom.xml#{Kurzbezeichnung}".
9. Qualitätssicherung
9.1. AdV-Qualitätssicherungssystem
Die AdV hat folgende Eckpunkte des Qualitätssicherungssystems für die Geodaten des amtlichen Vermessungswesens beschlossen:
"Durch bundeseinheitliche Festlegung, Benennung und beschreibende und quantitative Qualitätsmerkmale kennzeichnet und sichert die AdV die Qualität der geotopographischen und liegenschaftsbeschreibenden Produkte des amtlichen Vermessungswesens. Dabei sind die bundesweite Aktualität, Einheitlichkeit, Vollständigkeit und Verfügbarkeit der Produkte wesentliche Qualitätsmerkmale. Die Vermessungsverwaltungen gewährleisten die Einhaltung der AdV-Produktqualität durch standardisierte Prüfverfahren und erklären die Konformität mit den AdV-Standards."
Die Qualitätsprüfaspekte Q1 bis Q6 sind spezifisch für das AAA-Anwendungsschema, sie lassen sich prinzipiell aber auch auf andere Produktspezifikationen übertragen. Die Qualitätsprüfaspekte Q7 und Q8 gelten für die Bereitstellung von Geobasisdaten über Dienste. Q7 steht für die Qualitätssicherung der Austauschdaten gegenüber den Austauschschemata der Produktspezifikationen (Inhalt) und Q8 beschreibt die Qualitätssicherung der Dienste gegenüber den Profilen, Produktspezifikationen (Diensteparameter).
Ziel ist eine umfassende Qualitätssicherung für die Geodaten des amtlichen Vermessungswesens als Ergebnis des Konzeptions- und Produktionsprozesses. Die Konzeption (AAA-Basisschema, AAA-Fachschema; Profile für Dienste und Metadaten) liegt in den Händen der AdV, während die Produktion der Datenbestände im Einklang mit dem AAA-Anwendungsschema, die Beschreibung mit Metadaten und die Bereitstellung über Schnittstellen und Dienste Aufgabe der Vermessungsverwaltung eines jeden einzelnen Landes ist.
9.2. Qualitätssicherungsmodell für das AAA-Anwendungsschema
Angewendet auf das AAA-Anwendungsschema bedeuten die verschiedenen Qualitätsprüfaspekte (Q1 bis Q6) folgendes:
Q1 misst das AAA-Basisschema an den strategisch-fachlichen Vorgaben der AdV, Q2 misst das AAA-Fachschema an den fachlichen Vorgaben der AdV. Mit Q3 wird festgestellt, ob das AAA-Fachschema den Regeln des AAA-Basisschemas entspricht. Q1, Q2 und Q3 prüfen die konzeptionelle, interne Qualität.
Q4 prüft den Geobasisdatenbestand auf Übereinstimmung mit dem AAA-Anwendungsschema und auf die Einhaltung der dort niedergelegten Qualitätsangaben, z.B. die Konsistenzbedingungen der jeweiligen Version.
Q5 vergleicht den Geobasisdatenbestand mit der realen Welt , Q6 betrifft die Qualität der NAS zum Nutzer.
Im Einzelnen ergibt sich folgendes Qualitätsprüfungsschema:
| AdV | Länder | ||
|---|---|---|---|
1. |
AdV-Regelwerke und Standards zur Entwicklung von Verfahren und Programmsystemen |
||
Qualitätssicherung des AAA-Basisschemas gegenüber den Vorgaben der AdV (Q1) |
X |
||
Qualitätssicherung des gemeinsamen AAA-Fachschemas gegenüber den fachlichen Vorgaben der AdV (Q2) |
X |
||
Qualitätssicherung des gemeinsamen AAA-Fachschemas gegenüber dem AAA-Basisschema (Q3) |
X |
||
Qualitätssicherung der Datenbestände (ALKIS/ATKIS/AFIS) gegenüber dem gemeinsamen AAA-Anwendungsschema (Q4) |
X |
||
Qualitätssicherung der Austauschdaten gegenüber der NAS (Q6) |
Grundsätze |
X |
|
2. |
Vorgaben für die AdV-Produktqualität |
||
Festlegung von beschreibenden und bewertenden Qualitätsmerkmalen für einheitliche Produkte einschl. Aktualität, Einheitlichkeit, Vollständigkeit und Verfügbarkeit. |
X |
||
3. |
Vorgaben für Qualitätssicherung der Bestandsdaten |
||
Qualitätssicherung der Bestandsdaten gegenüber der fachlichen Realität (Q5) |
X |
||
4. |
Qualitätssicherung (als Teil des Qualitätsmanagements) |
||
Konformitätserklärung durch die Vermessungsverwaltungen |
X |
Die Qualitätssicherungsgrundsätze zu Q6 gehen davon aus, dass bei Datenabgaben aus
AFIS/ALKIS/ATKIS keine Überprüfung der entstehenden NAS-Dateien gegenüber dem Modell vorgenommen werden muss. Die modellkonforme Implementierung hat dies anhand der jeweils gültigen XML-Schemadateien (XSD) sicher zu stellen; die Interoperabilität ist zu gewährleisten. Die Datenübernahme ist Bestandteil des Qualifizierungsprozesses. In diesem Rahmen müssen entsprechende Prüfwerkzeuge zur Verfügung stehen, die anhand der jeweils gültigen XML-Schemadateien (XSD) die Qualität der Übernahmedaten sicherstellen. Die Prüfung der Austauschdaten gegenüber den NAS-Schema unterscheidet die Prüfung der Wohlgeformtheit der XML-Datei und die Prüfung der Gültigkeit der XML-Datei (Prüfwerkzeug für beides z.B. Xerces).
Die Ergebnisse der Qualitätssicherung für das AAA-Anwendungsschema sind in folgenden Dokumenten unter http://www.adv-online.de/veroeffentlichungen veröffentlicht.
Dokumente zum Qualitätsmanagement |
Qualitätssicherung des gemeinsamen AAA-Fachschemas gegenüber den |
Qualitätssicherung des gemeinsamen AAA-Fachschemas gegenüber |
Anlagen zu Q3 |
Qualitätssicherung der Austauschdaten gegenüber der NAS (Q6) |
9.3. AdV-Testsuite
Zur Gewährleistung der fach- und stellenübergreifenden Interoperabilität müssen die von den AdV-Mitgliedsverwaltungen geführten aktuellen Geobasisdaten und der daraus abgeleiteten Geodatendienste anhand der abgestimmten AdV-Spezifikationen überprüft werden. Die Interoperabilität ist die Voraussetzung, dass die Geobasisdaten, Geodatendienste und Metadaten tatsächlich auch bundesweit einheitlich von den Nutzern in ihren webbasierten Geoinformationssystemen verwendet werden können. Die AdV-Spezifikationen bilden den Maßstab der Datenqualitätsprüfungen.
Damit die jeweiligen AdV-Mitgliedsverwaltungen ihre Daten und Dienste prüfen können, wird eine geeignete Testplattform (AdV-Testsuite) bereitgestellt, mit der die Datenqualitätstests operationalisiert werden können. Dabei geht es nicht um eine offizielle Zertifizierung, sondern um den technischen Vorgang zur Überprüfung von Anforderungen aus AdV-Spezifikationen als Teil einer umfassenden Qualitätssicherung der amtlichen Geobasisdaten.
Die AdV-Testsuite deckt insbesondere folgende Konformitätsprüfungen ab:
-
Datentests für AdV-Produktstandards und technische Regelwerke (z.B. Produkte der GeoInfoDok, externe und interne Datenformatbeschreibungen der ZSHH, Produktstandard für Orthophotos),
-
AdV-Diensteprofile und AdV-Produktspezifikationen für Dienste (inkl. der AdV-INSPIRE-Produktspezifikationen für Dienste),
-
Metadaten.
Die begonnene Implementierung erfolgt nach einem Stufenkonzept. Der erste Realisierungsschritt umfasst zunächste nur die Konformitätstests für Daten der GeoInfoDok. Die Tests beziehen sich auf die in den AdV-Spezifikationen enthaltenen Anforderungen, in der Regel auf Vorgaben aus dem aktuellen AAA-Anwendungsschema. Abhängig von den Anwendungsfällen und von bestimmten Anforderungen der AdV-Mitgliedsverwaltungen können Tests offline und/oder online durchgeführt werden.
Für den Betrieb der AdV-Testsuite ist die strukturierte Erfassung und Pflege aller Testkriterien für alle AdV-Spezifikationen in einer zentralen Registry realisiert. Ein Prozessmodell zur Fortführung der Testkriterien ist ebenso festgelegt wie die konkreten Zuständigkeiten. Die Fortschreibung der Testkriterien der GeoInfoDok wird durch den AAA-Revisionsausschuss wahrgenommen.
Neben dem Betrieb der AdV-Testsuite wurde auch der Betrieb der technischen Plattform zur Führung der Testkriterien (Testsuite-Registry) sichergestellt. Die Testsuite-Registry ist somit das zentrale Verzeichnis sämtlicher Testkriterien, Testfälle und Konformitätsklassen für alle Spezifikationen (nicht nur GeoInfoDok). Auf AdV-online wird der Link auf die Registry mit den Testkriterien zu den jeweiligen GeoInfoDok-Versionen veröffentlicht.
9.4. Systematik und Dokumentation der Qualitätssicherung
Qualitätssicherung von Daten, Metadaten oder Diensten erfolgt immer gegen Anforderungen , die in Spezifikationen festgelegt worden sind.
Innerhalb einer Spezifikation werden Anforderungen zu einer oder mehreren Konformitätsklassen gruppiert. Konformitätsklassen sind dabei die Einheiten, gegen über denen man für einen Testgegenstand Konformität prüfen bzw. veröffentlichen will. Ein Testgegenstand der AdV ist vom Typ i.d.R. ein Datenbestand, ein Metadatensatz oder ein Webdienst. Alle Anforderungen in einer Konformitätsklasse beziehen sich stets auf denselben Typ von Testgegenständen.
Konformitätsklassen können untereinander Abhängigkeiten haben. Ist zum Beispiel eine Konformitätsklasse A von einer anderen Konformitätsklasse B abhängig, dann kann ein Prüfgegenstand nur konform zu A sein, wenn er auch konform zu B ist.
Für jede Konformitätsklasse werden jeweils Testkriterien spezifiziert, die alle Anforderungen der Klasse abdecken müssen. Ein Testkriterium stellt eine Testeinheit im Sinne einer kleinstmöglichen, unteilbaren und eigenständigen Testbedingung zur Prüfung einer einzelnen Qualitätsanforderung dar. Die Testkriterien werden innerhalb einer Konformitätsklasse wiederum zu sachlogisch zusammenhängenden Testfällen gruppiert.
Um die Erfüllung der Anforderungen prüfen zu können, müssen die notwendigen Tests für die Prüfung festgelegt werden. Im besten Fall sind in einer Spezifikation die Anforderungen bereits als solche klar ausgewiesen und sowohl eindeutig als auch testfähig formuliert. In diesem Fall ist die Festlegung der Testkriterien eher eine formale Arbeit. Im Normalfall lassen die Formulierungen in Spezifikationen Interpretationsspielräume und die fachliche Abstimmung der Testkriterien ist eine wichtige Aufgabe für eine verlässliche Prüfung.
Abbildung 50 zeigt die Begriffe im Kontext. Dabei wird auf der rechten Seite der Abbildung die Implementierung der spezifizierten Tests im Rahmen der AdV-Testsuite dargestellt. Die zugehörigen Begriffe werden weiter unten erläutert.
Abbildung 51 stellt den grundsätzlichen Aufbau einer Testumgebung wie der AdV-Testsuite dar.
Ein Testprojekt umfasst die Testfälle und Testkriterien einer Konformitätsklasse und wird zur automatisierten Prüfung in einem Testrahmen unter Verwendung einer Testkomponente verfügbar gemacht. Die Testkomponente ist eine Software zur Ausführung von Testläufen, bei denen ein Testgegenstand gegen ein oder mehrere Testprojekte geprüft wird. Die Ergebnisse werden im Testrahmen als Testbericht verfügbar gemacht. Basis des gesamten Systems ist ein zentrales Dokument, der sogenannte Testplan. Er beschreibt alle Aspekte der Tests und den verwendeten Ansatz.
Bei Datentests wird es in der Regel eine 1-zu-1-Beziehung zwischen fachlichen Testkriterien und ausführbaren Testkriterien geben, aber bei komplexeren Prüfabläufen wie bei den Tests von Webdiensten ist das nicht der Fall.
10. Glossar, Abkürzungen
10.1. Fachbegriffe und ihre englische Übersetzung
| Fachbegriff (deutsch) | Erläuterung | Fachbegriff (englisch) |
|---|---|---|
Die AdV schafft Regelwerke zur Entwicklung von Verfahren und Programmsystemen und zur Herstellung von Produkten. AdV-Regelwerke, die der Festlegung von bundeseinheitlichen Grunddatenbeständen, Datenaustauschschnittstellen und Standardprodukten dienen, werden durch Verpflichtung der Mitgliedsverwaltungen zu ihrer Einhaltung zu AdV-Standards erhoben. |
AdV-standard |
|
Das Basisschema und das anwendungsspezifische Subschema von AFIS, ALKIS und ATKIS (AAA-Fachschema) bilden zusammen das gemeinsame AFIS-ALKIS-ATKIS-Anwendungsschema. |
AFIS-ALKIS-ATKIS application schema |
|
🡪 siehe Basisschema |
AFIS-ALKIS-ATKIS basic schema |
|
Das AFIS-ALKIS-ATKIS-Referenzmodell ist ein gemeinsames Rahmenmodell, in dem die Strukturen und Inhalte der Produkte von AFIS, ALKIS und ATKIS, die Datenerfassungsquellen, Bestandsdaten sowie deren digitale und analoge Auszüge aus AFIS, ALKIS und ATKIS sowie die Abgabe der Daten an den Nutzer als Komponenten mit ihren gegenseitigen Beziehungen definiert sind. |
AFIS-ALKIS-ATKIS reference model |
|
Der Anlass gibt den Grund einer Veränderung eines Objektes wieder. Er wird als Attribut bei AA_Objekt neben dem Objektidentifikator und dem Lebenszeitintervall geführt. |
cause (for a change) |
|
Ein Anwendungsschema ist ein konzeptuelles Schema für Daten, die von einer oder mehreren Anwendungen benötigt werden. conceptual schema for data required by one or more applications |
application schema |
|
Attribute sind selbstbezogene Eigenschaften eines Objekts. Deren individueller Aufbau wird bei jeder Objektart als Attributart in den Objektartenkatalogen beschrieben. |
attribute |
|
Im Ausgabekatalog ist die Art und Weise der Aufbereitung und Ausgabe der Daten und Auszüge aus AFIS, ALKIS und ATKIS an den Nutzer spezifiziert. |
output catalogue |
|
Auszüge sind nach Inhalt, Gebiet und/oder Zeitraum (wie z. B. Fortführungsdatenbestände) selektierte Datenbestände, die an den Nutzer als objekt- oder bildstrukturierte Daten, aufbereitete Informationen oder analoge Auszüge abgegeben werden. |
extracts |
|
Das Basisschema ist ein Schema, das die grundlegenden Eigenschaften für eine oder mehrere Anwendungen beschreibt. Es enthält den einheitlichen und objektorientierten Modellansatz, auf dem die Subschemata von AFIS, ALKIS und ATKIS aufbauen. |
basic schema |
|
Bei Bestandsdaten handelt es sich um Geoinformationen des amtlichen Vermessungswesens in AFIS, ALKIS und ATKIS. Sie enthalten die vollständige Beschreibung von Fachobjekten einschließlich der Daten zu ihrer kartographischen oder textlichen Darstellung in einem oder mehreren Zielmaßstäben. |
(geographic) data in primary database |
|
Die Bestandsdatenaktualisierung ist ein Verfahren zur Fortführung von Sekundärdatenbeständen bei Nutzern mit Hilfe der Normbasierten Austauschschnittstelle (NAS). Das Verfahren wird mit "NBA-Verfahren" abgekürzt. |
update of primary database |
|
Bestandsobjekte sind Fachobjekte des Liegenschaftskatasters, die nach dem AFIS-ALKIS-ATKIS-Datenmodell modelliert wurden. |
features in primary database |
|
Ein Datenmodell beschreibt die grundlegenden Eigenschaften, die für alle Erscheinungen einer bestimmten (fachbezogenen) Sicht auf die Wirklichkeit eine einheitliche Abbildung erleichtern. Es bestimmt die grundsätzlichen Strukturen, die prinzipiell möglichen Beziehungen und die Eigenschaften, die zugeordnet werden können. |
data model |
|
→ siehe Modellierungssprache |
data modeling language |
|
Der Level of detail definiert die geometrische und thematische Auflösung von 3D-Objekten. Die Differenzierung zwischen den Detailierungsgraden wird in ALKIS® in Abhängigkeit von der Geometrie und/ oder der Texturierung vorgenommen werden. |
Level of detail |
|
Differenzdaten sind stichtagsbezogene Änderungsdaten, die nötig sind, um den Ausgangszustand der Bestandsdaten beim Nutzer auf den gewünschten Endzustand (Stichtag) zu bringen. Sie umfassen alle neu entstandenen Objekte, die jeweils aktuellen Versionen fortgeführter Objekte sowie Angaben zu historisch gewordenen Objekten. Die Differenzdaten stellen eine Untermenge der Änderungsdaten dar. |
Change-only data, differential update |
|
Ein Digitales Bildmodell ist ein Modell zur Speicherung von Bilddaten, z.B. digitalen Orthophotos. |
Digital image model |
|
Ein Digitales Geländemodell ist ein Digitales Höhenmodell mit zusätzlichen topographischen Informationen wie Bruchkanten etc. |
digital terrain model |
|
Ein Digitales Höhenmodell speichert Informationen über die Höhe von diskreten Punkten, die i.d.R. in einem regelmäßigen Gitter angeordnet sind. Diese Höheninformationen werden genutzt, um Höhen für alle anderen Positionen zu berechnen bzw. zu interpolieren. |
Digital elevation model |
|
Elementarobjekte stellen die kleinsten, fachlich eigenständigen Einheiten dar. Sie setzen sich nicht aus anderen eigenständigen Einheiten zusammen. Es gibt in der Modellierung für AFIS, ALKIS und ATKIS folgende Arten von Elementarobjekten:
→ siehe auch Zusammengesetztes Objekt (ZUSO)
|
Elementary objects |
|
Die Erhebungsdaten stellen die Grundlage zur Fortführung der amtlichen Geoinformationen dar. Sie werden durch Erhebungsprozesse aus Quelldaten, die mit den bekannten geodätischen Mess- und Erkundungsmethoden in der realen Welt erhoben oder aus kartographischen Darstellungen und anderen Unterlagen erfasst werden, gebildet. |
Collected data |
|
Der Erhebungsprozess erzeugt zur Qualifizierung und Fortführung der amtlichen Geoinformationen aus Quelldaten Erhebungsdaten. Der Erhebungsprozess ist nicht Bestandteil des Anwendungsschemas ALKIS und wird länderspezifisch modelliert. |
Data collection process |
|
Fachdaten sind anwendungsspezifische Daten eines Fachanwenders, z.B. Leitungsdaten oder Kundendaten eines Versorgungsunternehmens. Diese können mit einem Raumbezug versehen werden. |
Technical data |
|
Fachdatenobjekte sind Objekte in Fachinformationssystemen anderer Fachbereiche. |
Technical data object |
|
Die Fachdatenverbindung beinhaltet die Integrations- und Verknüpfungsmöglichkeiten zwischen den Daten der Vermessungsverwaltung (Basisdaten) und den Fachdaten in Form von Referenzen. Diese Verknüpfung kann entweder in den raumbezogenen Basisinformationssystemen der Vermessungsverwaltung, im Fachinformationssystem (einseitige Verknüpfung) oder gegenseitig in beiden Informationssystemen (gegenseitige Verknüpfung) erfolgen. |
Association to technical data |
|
System, das Informationen fachlicher Art enthält und Geobasisinformationen der Vermessungs- und Katasterverwaltung als Grundlage nutzt. |
Technical information system |
|
Ein Fachobjekt entsteht durch Abstraktion einen Gegenstandes oder Sachverhaltes der realen Welt. Im Anwendungsbereich von AFIS, ALKIS und ATKIS ist dies eingeschränkt auf die Gegenstände und Sachverhalte, die den fachlichen Gehalt von AFIS, ALKIS und ATKIS ausmachen. → Objekt abstraction of real world phenomena NOTE 1 A feature may occur as a type or an instance. Feature type or feature instance should be used when only one is meant. NOTE 2 UML uses feature for another concept than the use of feature within this standard. In UML, a property, such as operation or attribute, is encapsulated as part of a list within a classifier, such as an interface, a class or a data type. |
Feature |
|
Geodätischer Referenzpunkt |
geodetic control station |
|
Fortführung ist die Aktualisierung von Bestandsdaten. Die Fortführungsdaten (Daten und Metadaten) werden dabei durch Anwendung geeigneter Methoden in den Bestand überführt. |
Update, revision |
|
Der Fortführungsauftrag ist eine Objektart, die ein oder mehrere Fortführungsfälle zu einer Einheit zusammenfasst. Sie steuert das Verfahren der Datenaktualisierung für sämtliche Bestandsobjekte. |
Revision case or instance |
|
Beim Führungsprozess handelt es sich um die Ersteinrichtung bzw. Fortführung der Bestandsdaten (Geobasisdaten und Metadaten). |
Process of updating |
|
Geobasisdaten sind grundlegende amtliche Geodaten, welche die Landschaft (Topographie), die Flurstücke und die Gebäude im einheitlichen geodätischen Raumbezug anwendungsneutral beschreiben. Geobasisdaten werden durch die Vermessungsverwaltungen der Länder erhoben, geführt und bereitgestellt. Sie erfüllen die Funktion der Basisdaten für Geofachdaten. |
(geographic) reference data |
|
Geodaten sind Daten, die sich auf räumliche Objekte in Relation zum Erdkörper beziehen. |
Geographic data |
|
Geodatenbestand umfasst die Gesamtheit der geographischen Daten, die in einer Datenbank vorgehalten werden. |
Geographic database |
|
Geoinformationen sind Geodaten, die für eine bestimmte Anwendung ausgewählt, bearbeitet und aggregiert wurden. |
Geoinformation |
|
Ein Geoinformationssystem ist ein System zur Erfassung, Speicherung, Prüfung, Veränderung, Integration, Analyse und Darstellung von Geoinformationen. |
Geographic information system |
|
Unter Geokodierung versteht man die Zuordnung von Objekten (Daten, Informationen) zur Erdoberfläche mit Hilfe eines (räumlichen) Referenzsystems. |
Geocoding |
|
Als Grunddatenbestand wird der von allen Vermessungsverwaltungen der Länder der Bundesrepublik Deutschland bundeseinheitlich zu führende und dem Nutzer länderübergreifend zur Verfügung stehende Datenbestand (in AFIS, ALKIS und ATKIS) bezeichnet. |
(geographic) core data inventory |
|
Als Historisierung bezeichnet man das Entstehen der letzten Version (Untergang) eines Fachobjektes. |
Historization |
|
Der Identifikator kennzeichnet ein Objekt eineindeutig (unique). Er ist eine besondere selbstbezogene Eigenschaft des Objekts und steht stellvertretend für das Objekt, das er repräsentiert. Er bleibt so lange unverändert, wie das entsprechende Objekt existiert. Die für den AFIS-ALKIS-ATKIS-Datenaustausch definierte Austauschschnittstelle beruht auf der Anwendung der Norm ISO 19118 Encoding. Die daher Normbasierte Austauschschnittstelle wird mit "NAS" abgekürzt. |
Identifier |
|
Die Kardinalität ist die Mächtigkeit einer Menge bzw. die Anzahl der Elemente einer endlichen Menge. In der Modellierung wird dies durch den Bereich möglicher Kardinalitäten ausgedrückt. Gebräuchliche Bereichsangaben in den Objektartenkatalogen sind z.B.:
|
cardinality |
|
Kartengeometrieobjekte sind Fachobjekte, die bei der Ableitung für einen bestimmten Kartenmaßstab aus Gründen der kartographischen Generalisierung ihre geometrische Form und/oder Lage verändert haben. |
map geometry object |
|
Eine Klasse ist ein Begriff aus der objektorientierten Modellierung und beschreibt eine Menge von Objekten, die sich durch die gleichen Attribute, Methoden, Relationen und das gleiche (dynamische) Verhalten auszeichnen. descriptor of a set of objects that share the same attributes, operations, methods, relationships, and behaviour NOTE A class represent a concept within the system being modelled. Depending on the kind of model, the concept may be real-world (for an analysis model), or it may also contain algorithmic and computer implementation concepts (for a design model). A classifier is a generalization of class that includes other class-like elements, such as data type, actor and component. NOTE A class may use a set of interfaces to specify collections of operations it provides to its environment. |
class |
|
Die Kodierung ist die Abbildung von Informationen (Daten, Objekte) in ein (maschinenlesbares) Schlüsselsystem (Verschlüsseln); die inverse Abbildung ist die Dekodierung. |
encoding |
|
Ein konzeptuelles Modell ist als Abbild der realen Welt bezüglich konkreter Fachthemen zu verstehen. model that defines the concepts of a universe of discourse |
conceptual model |
|
Das konzeptuelle Schema beschreibt das konzeptuelle Modell mit Hilfe einer formellen Sprache. schema of a conceptual model A conceptual schema classifies objects into types and classes, identifying types of objects according to their properties and associations between types of objects. |
conceptual schema |
|
Metadaten sind Daten über Daten. Sie dienen der Beschreibung der Geodaten hinsichtlich nutzerrelevanter Aspekte zur Bewertung der Eignung der Daten und des Zugriffs auf dieselben. ISO unterscheidet etwa 400 optionale, obligatorische und bedingt obligatorische Metadatenelemente. data describing and documenting data |
metadata |
|
Ein Metadatenkatalog ist ein Katalog mit beschreibenden Daten (Metadaten). Er enthält für jeden Datenbestand insbesondere Angaben über den Inhalt, die Darstellung, die Ausdehnung (sowohl geometrisch als auch zeitlich), den Raumbezug, die Qualität und die verantwortliche Institution, aufgrund derer ein Nutzer die Verfügbarkeit und Eignung der Geodatensätze für seine Zwecke bewerten kann. |
metadata catalogue |
|
Metaobjektklassen bzw. Metaklassen werden definiert, um auf deren Basis Fachobjekte zu instanziieren. Bei der Modellierung der Basisklassen wurde eine raumbezogene Metaobjektklasse (GF_FeatureType aus ISO 19109) verwendet. |
metaclass |
|
Eine Methode ist eine an ein Objekt gebundene Funktion. Sie hat nur Auswirkungen auf dieses Objekt selbst bzw. auf dessen Eigenschaften (Attribute, Geometrie und Relationen). |
method |
|
Ein Modell ist eine vereinfachende bildliche oder mathematische Darstellung von Strukturen und des Verhaltens komplexer Sachverhalte der realen Welt. Es dient der Lösung bestimmter Aufgaben, deren Bewältigung am Original unmöglich oder unzweckmäßig ist. model abstraction of some aspects of reality |
model |
|
Eine Modellierungssprache bietet darstellende und/oder lexikalische (textliche) Elemente zur Beschreibung eines Modells. Für die Modellierung im Fachbereich AFIS-ALKIS-ATKIS wird gemäß ISO 19103 die Unified Modeling Language (UML) verwendet. formal language based on a conceptual formalism for the purpose of representing conceptual schemas EXAMPLE UML, EXPRESS, IDEFIX NOTE A conceptual schema language may be lexical or graphical. |
conceptual schema language |
|
Normen dienen der Standardisierung verschiedenster Bereiche menschlichen Wirkens. Eine Art von Normen sind ISO-Normen: Dokumente, die von Mitgliedern der International Organization for Standardization (ISO) in sogenannten Technical Committees (TC) im Rahmen eines mehrstufigen Entwicklungsprozesses erstellt werden. Für Geoinformation ist das TC 211 "Geographic information/Geomatics" zuständig (siehe http://www.isotc211.org/). Dabei durchlaufen diese Dokumente mehrere Reifestadien. Endstadium ist das des "International Standard".. |
de-jure standards |
|
Operation zur Fortführung von sekundären Datenbeständen mit Hilfe von Differenzdaten bzw. Änderungsdaten. |
user-specific updating of secondary databases |
|
Ein Objekt (Instanz einer Klasse) ist ein materieller oder immaterieller Gegenstand der fachlichen Realität, der eindeutig identifizierbar und durch Abstraktion auf seine relevanten Eigenschaften beschränkt ist. Dies schließt seinen Zustand und sein Verhalten ein. a discrete entity with a well-defined boundary and identity that encapsulates state and behaviour; an instance of a class |
object |
|
Objekte werden nach verschiedenen Objektarten klassifiziert. Für jede Objektart werden im Objektartenkatalog alle erlaubten Eigenschaften festgelegt (Typenebene). Diese Festlegungen gelten dann für alle Ausprägungen (Instanzenebene), das sind die einzelnen Objekte dieser Art, uneingeschränkt. Jedes Objekt gehört zu genau einer Objektart. class of real world phenomena with common properties EXAMPLE The phenomenon 'Eiffel Tower' may be classified with other similar phenomena into a feature type 'tower'. NOTE In a feature catalogue, the basic level of classification is the feature type. |
feature type |
|
Der Objektartenkatalog führt für alle Objektarten abschließend die auf der Grundlage des AFIS-ALKIS-ATKIS-Anwendungsschemas modellierten Datenelemente mit ihren Festlegungen auf. catalogue containing definitions and descriptions of the feature types, feature attributes, and feature relationships occurring in one or more sets of geographic data, together with any feature operations that may be applied |
feature catalogue |
|
Der Objektbehälter bildet eine datentechnische Klammer um die verschiedenen Versionen eines Objekts, die dieses im Verlauf seines Lebens durchläuft. Durch "Klammerung" der Versionen innerhalb eines Objektbehälters bleibt die fachliche Objektsicht stets erhalten. |
container for feature versions |
|
object identifier |
||
Grundlage der Objektorientierung, die sowohl bei der objektorientierten Modellierung von Systemen und Prozessen, bei der objektorientierten Programmierung als auch bei objektorientierten Datenbankmanagementsystemen eingesetzt wird, ist die Abstraktion der Realität in Objekte, Klassen und Beziehungen. Die Objektorientierung ist damit eine Methode (Konzept, Sprache) zur Modellierung von Sachverhalten, bei der sämtliche erforderlichen Informationen (Daten und Methoden) als gekapselte Objekte, die miteinander kommunizieren können, aufgefasst werden. |
object orientation |
|
Objektstrukturierung besagt, dass die in einem Anwendungsschema modellierten Sachverhalte in der Struktur von Objekten vorliegen und nach Objekten geordnet sind. Im Gegensatz zur Objektorientierung wird bei der objektstrukturierten Modellierung das Verhalten eines Objekts, das durch seine Methoden repräsentiert wird, nicht beschrieben. |
object structuring |
|
Präsentationsobjekte sind raumbezogene Elementarobjekte, welche die Fachobjekte um Angaben zur Darstellung von Schrift und Signaturen ergänzen. Dabei werden all jene Texte und Signaturen definiert, die nicht vollautomatisch für einen bestimmten Zielmaßstab einer Karte erzeugt und platziert werden können. Präsentationsobjekte sind in dem Objektartenkatalog zu definieren, auf dem sie aufbauen (z.B. ATKIS-Basis-OK). |
presentation object |
|
Der Primärnachweis ist der originäre, von der entsprechend fachlich zuständigen Stelle (Datenherr) geführte Datenbestand. |
primary database |
|
Ein Protokollobjekt dient der Übermittlung von Protokollinformationen. |
protocol object |
|
Ein Prozess überführt einen Quelldatenbestand in einen Zieldatenbestand. Zur Beschreibung von Prozessen (Vorgänge, Methoden) werden die Sprachmittel textliche, formularmäßige Beschreibung und Pseudocode verwendet. Die "Prozesse in ALKIS" enthalten die Definitionen und Beschreibungen der Methoden und Vorgänge sowie die Prozessobjektarten zur Steuerung der Prozesse. |
process |
|
Der Pseudocode ist ein Sprachmittel zur Beschreibung eines Prozesses. In ihm erfolgt die Beschreibung der Bearbeitungsschritte eines Vorgangs mit der folgenden Notation: "objektart.methode (parameter)". |
pseudocode |
|
Ein PunktLinienThema im Sinne der Modellierung beinhaltet die Möglichkeit, Fachobjekte so zu gruppieren, dass sie Geometrien gemeinsam nutzen. Dies führt dazu, dass exakt übereinanderliegende Linien und Punkte sich gegenseitig zerschlagen und zu redundanzfreien Geometrien vereinigen. Sich kreuzende Linien führen nicht zur gegenseitigen Zerschlagung. Überlappende Flächen zerschlagen sich nicht zu den jeweils kleinstmöglichen Teilflächen. |
point and line theme |
|
Der Qualifizierungsprozess überführt die Erhebungsdaten (Ausgangsdaten) in die Fortführungsdaten (Zieldaten). Er dient der Qualitätssicherung und stellt sicher, dass die Fortführungsdaten den Qualitätsanforderungen entsprechen. |
qualifying process |
|
Der Raumbezug ist die geometrische (Lage und Form des Objekts) und/oder die topologische (Lagebeziehungen zwischen Objekten) Beschreibung eines Objekts und stellt somit den Bezug des Objekts zu einem räumlichen Ausschnitt der Erde her. |
spatial reference |
|
Raumbezugsgrundformen sind von der ISO-Norm 19107 Spatial schema für die Verwendung in Anwendungsschemata zur Verfügung gestellte, vordefinierte "Geometrische Objekte" (GM_Objekt) und "Topologische Objekte" (TP_Objekt), die als UML-Klassen beschrieben sind. Die Raumbezugsgrundformen werden in der Regel als Attributwerte der Objekte geführt. |
geometrical and topological primitives |
|
Unter dem Begriff "Relation" wird ganz allgemein eine semantische Verbindung zwischen Modellelementen verstanden. Relation ist der Oberbegriff, unter dem die Begriffe Assoziation, Generalisierung/Spezialisierung, Abhängigkeit und Realisierung/Verfeinerung subsummiert werden. |
relation |
|
Ein Schema ist eine anschauliche (bildliche) Darstellung des Wesentlichen eines Sachverhalts. Es ist das Ergebnis der darstellenden und/oder lexikalischen (textlichen) Beschreibung eines Modells mit Hilfe einer (normierten) Modellierungssprache. |
schema |
|
Der Sekundärnachweis beinhaltet eine Kopie des gesamten Primärnachweises oder von Teilen desselben, die laufend aktualisiert wird. Die Fortführung des Sekundärnachweises erfolgt über die Nutzerbezogene Bestandsdatenaktualisierung (NBA). |
secondary database |
|
Ein Signaturenkatalog enthält Regeln, nach denen die im Ausgabekatalog definierten Ausgaben von Geodaten in Abhängigkeit von ihrem Objekttyp, von bestimmten Attributen/Attributwerten, von bestimmten Referenzbedingungen und/oder von zu berechnenden Werten signaturiert werden, und die Beschreibung aller vorkommenden Signaturen. Er ist an den jeweiligen Zielmaßstab angepasst. |
portrayal catalogue |
|
Ein Standard ist ein breit akzeptiertes und angewandtes Regelwerk. Er wird meist nur von einer Institution erzeugt, d.h. es existiert dafür kein internationales Gremium. Die Verbindlichkeit eines Standards geht oft nicht über eine einzelne Organisation hinaus. Ein Standard wird nicht offiziell international herausgegeben, wie dies bei Normen der Fall ist. Einen regulären Ablauf der Entstehung (wie bei Normen z.B. von DIN, ISO oder CEN) gibt es nicht. |
de-facto standard |
|
Mit Standardausgaben werden Regelfälle der Benutzung (auch im Sinne einheitlicher Produkte der AdV) abgedeckt. Es sind Ausgabeprodukte der AFIS-ALKIS-ATKIS-Daten, die normalen bzw. "normierten" Ansprüchen an die entsprechenden Datenbestände Genüge tun. Sie werden über die Definition einheitlicher Selektions- und Filterkriterien festgelegt. Beispiele von Standardausgaben für ALKIS sind die Liegenschaftskarte, der Flurstücks- und Eigentümernachweis und die Liegenschaftskarte mit Flurstücks- und Eigentümerangaben. |
standard output |
|
subschema |
||
Siehe Abschnitt 3.10.3.5 |
transfer process |
|
Uniform Resource Identifier Zeichenkette, die eindeutig auf eine Ressource (Name, Datei etc.) verweist. Der Ort der Ressource ist nicht eingeschränkt (www, LAN, …). URLs (Uniform Resource Locator) und URNs (Uniform Resource Name) sind Teilmengen von URIs. |
URI (Uniform Resource Identifier) generic set of all names/addresses that are short strings that refer to resources |
|
Versionierung ist die zeitlich geordnete Veränderung von Fachobjekten durch die Fortführung. Kernpunkt des Versionskonzeptes ist die Überlegung, dass jedes Fachobjekt neben anderen Informationen ein Lebenszeitintervall (bestehend aus Entstehungs- und Untergangsdatum/-zeit) führt. |
versioning |
|
Das Versionierungsschema ist Teil des konzeptuellen Basisschemas und beschreibt Aspekte der zeitlichen Veränderung der Fachobjekte durch Fortführungen. |
versioning schema |
|
Siehe Abschnitt 3.10.2 |
operation |
|
Das XML-Schema ist die lexikalische Beschreibung eines Anwendungsschemas auf der Basis von XML (Extensible Markup Language). Auf der Grundlage der im XML-Schema festgelegten Strukturen können XML-Dokumente zum Austausch von Daten geschaffen werden. Vgl. http://www.w3.org/TR/xmlschema-0/. |
XML schema |
|
Der Zeitstempel besteht aus Entstehungsdatum/-zeit, welche aus dem Attribut "Lebenszeitintervall" übernommen werden. Er ist als Ergänzung zum Objektidentifikator gedacht und soll bei der Fortführung das gezielte Identifizieren von Objektversionen ermöglichen. |
time stamp |
|
Zusammengesetzte Objekte werden gebildet, um den Zusammenhang zwischen einer beliebigen Zahl und Mischung semantisch zusammengehörender raumbezogener Elementarobjekte, nicht raumbezogener Elementarobjekte oder zusammengesetzter Objekte herzustellen. Ein zusammengesetztes Objekt muss aber mindestens ein Elementarobjekt als Bestandteil besitzen. siehe auch Elementarobjekt |
composed object or complex object |
10.2. Abkürzungsverzeichnis
| Abkürzung | Langtext |
|---|---|
AdV |
Arbeitsgemeinschaft der Vermessungsverwaltungen der Länder der Bundesrepublik Deutschland |
AFIS |
Amtliches Festpunktinformationssystem |
ALB |
Automatisiertes Liegenschaftsbuch |
ALK |
Automatisierte Liegenschaftskarte |
ALKIS |
Amtliches Liegenschaftskataster Informationssystem |
ATKIS |
Amtliches Topographisch-Kartographisches Informationssystem |
ATS |
Abstract Test Suite |
BKG |
Bundesamt für Kartographie und Geodäsie |
CD |
Commitee Draft |
CER |
Code-Listen- und Enumerations-Registry |
CityGML |
City Geography Markup Language |
CRS |
Coordinate Reference System |
CSL |
Conceptual Schema Language |
DaBaG |
DatenbankGrundbuch |
DB |
Datenbank |
DBM |
Digitales Bildmodell |
DGM |
Digitales Geländemodell |
DHM |
DigitalesHoehenModell |
DLKM |
LiegenschaftskatasterModell |
DLM |
Digitales Landschaftsmodell |
DOP |
Digitales Orthophoto |
DTD |
Document Type Definition |
DTK |
Digitale Topographische Karte |
DXF |
Data Exchange Format |
FIS |
Fachinformationssystem |
GBO |
Grundbuchordnung |
GBV |
Verordnung zur Durchführung der Grundbuchordnung |
GeoBasis-DE |
Modellart für LandbedeckungLandnutzung |
GeoInfoDok |
Dokumentation zur Modellierung der Geoinformationen des amtlichen Vermessungswesens |
GIS |
Geoinformationssystem |
GML |
Geography Markup Language |
GV |
Geometrische Verbesserungen |
GVM |
GeometrischesVerbesserungsModell |
ID |
Identifikator / Identifier |
IFC |
Industry Foundation Classes (Standard zur digitalen Beschreibung von Gebäudemodellen) |
INSPIRE |
Infrastructur for Spatial Information in Europe |
ISO |
International Organization for Standardization |
LB |
Landbedeckung |
LN |
Landnutzung |
LoD |
Level of detail (Detailstufen) |
NAS |
Normbasierte Austauschschnittstelle |
NBA |
Nutzerbezogene Bestandsdatenaktualisierung |
NREO |
Nicht raumbezogenes Elementarobjekt |
OGC |
Open Geospatial Consortium |
OK |
Objektartenkatalog |
REO |
Raumbezogenes Elementarobjekt |
SK |
Signaturenkatalog |
TC |
Technical Commitee |
TK |
Topographische Karte |
UML |
Unified Modeling Language |
URI |
Uniform Resource Identifier |
URL |
Uniform Resource Locator |
URN |
Uniform Resource Name |
UUID |
Universally Unique Identifier |
XML |
Extensible Markup Language |
ZUSO |
Zusammengesetztes Objekt |
10.3. Abbildungsverzeichnis
Abbildung 1. Gemeinsames AFIS-ALKIS-ATKIS-Referenzmodell
Abbildung 2. Die Rolle des Anwendungsschemas
Abbildung 3. Abhängigkeit des AFIS-ALKIS-ATKIS-Anwendungsschemas von den genormten Strukturen aus OGC
Abbildung 4. Verwendete Teile aus der Normfamilie ISO 19100 (Auszug aus dem UML-Datenmodell)
Abbildung 5. Die Bestandteile des AFIS-ALKIS-ATKIS-Anwendungsschemas
Abbildung 6. Das Basisschema als Grundlage für anwendungsspezifische Fachschemata (z.B. AFIS, ALKIS und ATKIS)
Abbildung 7. Bestandteile des AAA-Basisschemas
Abbildung 8. Modellierung der AAA-Basisklassen
Abbildung 9. Zusammenfassende Darstellung der für AFIS-ALKIS-ATKIS erforderlichen Ergänzungen am genormten Spatial Schema
Abbildung 10. Auswahldatentypen zur Bildung unterschiedlicher geometrischer Objektinstanzen
Abbildung 11. Objekte mit gemeinsamer Geometrie
Abbildung 12. Gemeinsam genutzte Grenzfläche bei 3D-Objekten
Abbildung 13. 2D-Objekte mit unabhängiger Geometrie
Abbildung 14. Objekte mit unabhängiger Geometrie 3D
Abbildung 15. 3D-Objekte mit unabhängiger Geometrie
Abbildung 16. Präsentationsobjekte
Abbildung 17. Präsentationsablauf für die Karte
Abbildung 18. Präsentationsablauf für die Liegenschaftsbeschreibung
Abbildung 19. Präsentationsablauf in der Erhebung / Fortführung
Abbildung 20. Präsentationsobjekte_3D
Abbildung 21. Modellierung der Punktmengenobjekte
Abbildung 22. Modellarten im Basisschema
Abbildung 23. LoD 1
Abbildung 24. LoD 2
Abbildung 25. LoD 3
Abbildung 26. 3D-Transformationsmatrix
Abbildung 27. Versionierungsschema
Abbildung 28. Beispiel zur Versionierung nach Änderung von Attributen
Abbildung 29. Beispiel zur Versionierung nach Änderung von Relationen
Abbildung 30. Beispiel für eine zurückgezogene Objektart (AX_Grenzuebergang)
Abbildung 31. Beispiel für eine zurückgezogene Attributart ('bezeichnung' in AX_Schleuse)
Abbildung 32. Neue Attributart 'abgabeversion' zur Selektion von Objekten verschiedener GeoInfoDok-Versionen
Abbildung 33. Erweiterungen der genormten Struktur der Objektartenkataloge
Abbildung 34. Schema SK-Objektmodell
Abbildung 35. Prozesse und Daten der Geoinformationen des amtlichen Vermessungswesens
Abbildung 36. Vorgänge im AAA-Anwendungsschema
Abbildung 37. Ausgabeschema von ALKIS
Abbildung 38. Klassendiagramm "AA_Antrag"
Abbildung 39. Klassendiagramm "AA_Projektsteuerungskatalog"
Abbildung 40. Klassendiagramm "AA_Meilenstein"
Abbildung 41. Zweistufiger Ableitungsprozess der NAS
Abbildung 42. Einbettung der NAS in Normen und Standards
Abbildung 43. XML-basierende Kodierungsregeln gemäß ISO 19118
Abbildung 44. Erläuterung zur Linienteilung
Abbildung 45. Das UML-Paket "NAS-Operationen" im Kontext der Bestandteile des Anwendungsschemas
Abbildung 46. Geänderte Objektart AX_Nutzerbezogene-BestandsdatenaktualisierungNBA
Abbildung 47. Prototyp CRS-Registry der AdV
Abbildung 48. Das AdV-Qualitätssicherungsmodell für AAA und Dienste
Abbildung 49. Das Qualitätssicherungsmodell des AFIS-ALKIS-ATKIS-Projektes
Abbildung 50. Hierarchie von Konformitätsklasse, Testfall und Testkriterium
Abbildung 51. Schematischer Ablauf von Datentests
10.4. Tabellenverzeichnis
Tabelle 1. LoD 1-3 mit geometrischen Genauigkeiten
Tabelle 2. Beispiel für die Nutzung von Geometriebibliotheken
Anhang A: Implizite Funktionalitäten
A.1. Vorbemerkungen
Erläuterungen zu den Tabellen:
-
Referent = Das Objekt, welches zeigt.
-
Referenz = Die Verbindung (Relation) zwischen den Objekten, d.h. das, womit gezeigt wird. In Sp. 2 der Tabellen wird stets nur die bevorzugte Relationsrichtung genannt.
-
Referenziertes = Das Objekt, worauf gezeigt wird.
-
"Objekt Löschen" bedeutet, dass die aktuelle Version des untergehenden Objektes ein Untergangsdatum erhält. Die bei Führung der "Rumpfhistorie" zu einem späteren Zeitpunkt notwendige Entfernung des untergegangen Objektes aus dem Bestand wird durch die impliziten Funktionen vorbereitet.
-
"Referenz Löschen" bedeutet in Abhängigkeit von der Art der Referenz, dass
-
eine neue Version des Objektes ohne die genannte ("bevorzugte") Referenz gebildet wird ("Versionierung" des Objektes). Die bei Führung der "Rumpfhistorie" zu einem späteren Zeitpunkt notwendige Entfernung der historischen Version des Objektes aus dem Bestand wird damit vorbereitet. o d e r
-
die Referenz aus der aktuellen Version des Objektes entfernt wird (bei Löschen der implementierungsspezifischen "Gegenreferenz" keine "Versionierung" des Objektes).
-
Hinweis: Die teilweise in vorhandenen Systemen bestehende Mehrfachbedeutung von Punkten (z.B.: Ein Punkt ist gleichzeitig Aufnahmepunkt und Grenzpunkt) wird in den neuen Datenstrukturen entzerrt: Solche Punkte werden zu verschiedenen Fachobjekten. Dadurch verlagert sich mit der Mehrfachbedeutung verbundene Problematik im Zusammenhang mit impliziter Funktionalität zum Teil auf die Geometrieebene. Ausnahme: AU_*-Modellteile. Hier gilt: Abgeleitete Objekte dürfen sich keine Geometrie mit anderen Objekten teilen. Mehrfachbedeutung wird dadurch ausgeschlossen.
Implizite Funktionalität soll in einer Art Kettenreaktion wiederum implizite Funktionalität bewirken können. Beispiel:
AX_Buchungsstelle wirdVerwaltetVon AX_Verwaltung haengtAn AX_Person. Wird AX_Person gelöscht und ist in der Folge auch AX_Verwaltung implizit zu löschen, so ist als weitere Folge auch die Relation wirdVerwaltetVon implizit zu löschen.
Es werden nur Implizite Funktionen aufgeführt, die als Folge der Löschung (in Ausnahmefällen auch der Eintragung) von Objekten notwendig sind. Auch die Löschung und Veränderung von Relationen und Attributen können Folgemaßnahmen zur Aufrechterhaltung der Konsistenz der Datenbank erfordern; diese Maßnahmen sind jedoch entweder interaktiv oder implizit am Erhebungs- bzw. Qualifizierungsarbeitsplatz zu generieren. Vom System für die Datenhaltung ist zu fordern, dass Änderungen, deren Ergebnis den Festlegungen der 3A- Kataloge zuwiderläuft, abgelehnt werden oder zumindest eine entsprechende Meldung erzeugen.
Generell obliegt es den Systemen zum Primär- bzw. Sekundärnachweis dafür zu sorgen, dass die den Fachobjekten zugrunde liegenden geometrischen und topologischen Strukturen konsistent im Sinne von ISO 19107 sind und bleiben. In den Tabellen wird daher auf Details diesbezüglich nicht konkret eingegangen.
A.2. Implizite Funktionen im Führungsprozess für ein System zum Primärnachweis
In der Zusammenstellung der Impliziten Funktionen im Führungsprozess für ein System zum Primärnachweis wird unterschieden zwischen allgemein gültigen Funktionen, die für alle Objektarten des 3A- Anwendungsschemas gleichermaßen notwendig sind (Teil B1), und den besonderen Funktionen, die für einzelne Objektarten (und ggf. Relationen) gefordert werden (Teil B2). Der Hinweis im Teil B2 "Keine besondere implizite Funktion" bedeutet, dass die im Teil B1 festgelegten "Allgemeinen Impliziten Funktionen" anzuwenden sind.
A.2.1. Allgemein gültige Festlegungen für das AAA- Anwendungsschema
Zu löschendes Objekt |
Betroffene Relation |
"Implizit" betroffene Objektart |
Aktion der Datenhaltungskomponente |
|
Objekt in Sp.1 wird gelöscht, wenn nichts anderes gesagt wird. |
Art des Mangels |
(D.h. was mit den Objekten in Spalte 3 bzw. der Referenz geschehen soll) |
||
Nr. |
Spalte 1 |
Spalte 2 |
Spalte 3 |
Spalte 4 |
a) |
Objekt A NREO, REO, ZUSO REFERENT |
… |
Objekt B NREO, REO, ZUSO REFERENZIERTES |
Wird Objekt A gelöscht, so werden mit ihm auch seine Referenzen, Überführungs- und Unterführungsrelationen gelöscht. |
b) |
Objekt A wird eingetragen NREO, REO, ZUSO REFERENT |
… Gegenreferenz fehlt |
Objekt B NREO, REO, ZUSO REFERENZIERTES |
|
c) |
Objekt A NREO, REO, ZUSO REFERENT |
… Referenz fehlt |
Objekt B NREO, REO, ZUSO REFERENZIERTES |
|
d) |
Objekt A NREO, REO, ZUSO REFERENZIERTES |
… Referenz sinnlos |
Objekt B NREO, REO, ZUSO REFERENT |
|
e) |
Objekt A NREO, REO, ZUSO REFERENT |
istTeilVon Referenz fehlt |
Objekt B ZUSO REFERENZIERTES |
|
f) |
Objekt A REO, ZUSO REFERENZIERTES |
dientZurDarstellungVon Referenz sinnlos |
Objekt der Objektartengruppe "Präsentation" oder "Kartengeometrie" REO REFERENT |
Prüfung, ob das Objekt in Spalte 3 noch andere Objekte referenziert
|
A.2.2. Festlegungen für einzelne Relationen des AFIS-Subschemas
Zu löschendes Objekt |
Betroffene Relation |
"Implizit" betroffene Objektart |
Aktion der Datenhaltungskomponente |
|
Objekt in Sp.1 wird gelöscht, wenn nichts anderes gesagt wird. |
Art des Mangels |
(D.h. was mit den Objekten in Spalte 3 bzw. der Referenz geschehen soll) |
||
Nr. |
Spalte 1 |
Spalte 2 |
Spalte 3 |
Spalte 4 |
Objekt wird eingetragen: AX_Lagefestpunkt, AX_Höhenfestpunkt, AX_Schwerefestpunkt, AX_Referenzstations- punkt ZUSO |
(Keine Relation!) Name der Objektart in Sp. 1 semantisch identisch mit der Werteart des Attributes 'Art' des Objektes AX_Reservierung sowie Identität der Attributinhalte 'Punktkennung' |
AX_Reservierung NREO |
|
|
A.2.3. Festlegungen für einzelne Relationen des ALKIS- Subschemas
Zu löschendes Objekt |
Betroffene Relation |
"Implizit" betroffene Objektart |
Aktion der Datenhaltungskomponente |
|
Objekt in Sp.1 wird gelöscht, wenn nichts anderes gesagt wird. |
Art des Mangels |
(D.h. was mit den Objekten in Spalte 3 bzw. der Referenz geschehen soll) |
||
Nr. |
Spalte 1 |
Spalte 2 |
Spalte 3 |
Spalte 4 |
00000 |
Objekt wird eingetragen: AX_Flurstueck, |
(Keine Relation!) Name der Objektart in Sp. 1 semantisch identisch mit der Werteart des Attributes 'Art' des Objektes AX_Reservierung sowie Identität der Attributinhalte 'Punktkennung' bzw. 'Flurstueckskennzeichen' bzw. 'Fortführungsnummer' bzw. 'Abmarkungsprotokollnummer' mit 'Nummer' |
AX_Reservierung |
|
11001 |
AX_Flurstueck |
istGebucht |
AX_Buchungsstelle |
Prüfen, ob AX_Buchungsstelle noch anderweitig referenziert wird Falls nein: AX_Buchungsstelle löschen und gelöschte Objektart mit OID im Protokoll ausgeben |
11001 |
AX_Flurstueck |
gehoertAnteiligZu |
AX_Flurstueck |
Hier wird ein Ersatzobjekt benötigt, daher:
|
11001 |
AX_Flurstueck |
weistAuf |
AX_LagebezeichnungMitHausnummer |
Prüfen, ob AX_LagebezeichnungMitHausnummer noch anderweitig referenziert wird
|
11001 |
AX_Flurstueck |
zeigtAuf |
AX_LagebezeichnungOhneHausnummer |
Prüfen, ob AX_LagebezeichnungOhneHausnummer noch anderweitig referenziert wird
|
11001 |
AX_Flurstueck |
beziehtSichAuf |
AX_Vertretung REFERENT |
Prüfen, ob AX_Vertretung noch andere Flurstücke referenziert.
|
11003 |
AX_Grenzpunkt |
zeigtAuf |
AX_Grenzpunkt REFERENT |
Warnhinweis im Protokoll ausgeben. |
11003 |
AX_Grenzpunkt |
istTeilVon |
AX_PunktortTA |
Prüfen, ob Objekt in Spalte 3 weitere ZUSOs referenziert;
|
13001 |
AX_Aufnahmepunkt REFERENT |
hat |
AX_Sicherungspunkt REFERENZIERTES |
Warnhinweis im Protokoll ausgeben. |
14002 |
AX_PunktortAG REFERENT |
istTeilVon |
AX_BesondererGebaeudepunkt ZUSO REFERENZIERTES |
Prüfung, ob AX_BesondererGebaeude-/Bauwerkspunkt noch weitere Punktorte hat.
Da nicht gewünscht ist, die implizit betroffenen OA punktortweise zu löschen, wird keine weitere implizite Funktionalität gefordert. |
14003 |
AX_PunktortAU REFERENT |
istTeilVon |
(indirekt abgemarkter) REFERENZIERTES |
Prüfung, ob Objekt in Spalte 3 noch weitere Punktorte hat.
Da nicht gewünscht ist, die implizit betroffenen OA punktortweise zu löschen, wird keine weitere implizite Funktionalität gefordert. |
14004 |
AX_PunktortTA REFERENT |
istTeilVon |
AX_Grenzpunkt REFERENZIERTES |
Prüfung, ob AX_Grenzpunkt noch weitere Punktorte hat.
Da nicht gewünscht ist, die implizit betroffenen OA punktortweise zu löschen, wird keine weitere implizite Funktionalität gefordert. |
21001 |
AX_Person REFERENZIERTES REFERENT |
… |
AX_ … |
Auf implizite Funktionalität wird im Wesentlichen verzichtet, da hier recht komplexe Verflechtungen bestehen können. Die einfacheren Fälle werden nachfolgend aufgeführt. |
21001 |
AX_Person |
bestehtAus |
AX_Personengruppe REFERENZIERTES |
Prüfen, ob AX_Personengruppe von anderen Objekten referenziert wird
Multiplizität der Relation ist [2..*], so dass die Unterschreitung von 2 referenzierten Objekten AX_Person zur impliziten Löschung der Personengruppe führt. |
21001 |
AX_Person |
hat |
AX_Anschrift |
Prüfen, ob AX_Anschrift von anderen AX_Person oder AX_Dienststelle referenziert wird
|
21001 |
AX_Person |
benennt |
AX_Namensnummer |
Hier wird meist ein Ersatzobjekt benötigt, daher:
|
21001 |
AX_Person REFERENT |
wirdVertretenVon |
AX_Vertretung REFERENZIERTES |
|
21001 |
AX_Person REFERENZIERTES |
haengtAn |
AX_Vertretung REFERENT |
Prüfen, ob AX_Vertretung anderes Objekt AX_Person mit "haengtAn" neu referenziert oder von anderen Objekten referenziert wird
|
21001 |
AX_Person |
haengtAn |
AX_Verwaltung REFERENT |
Prüfen, ob AX_Verwaltung anderes Objekt AX_Person mit "haengtAn" neu referenziert oder von anderen Objekten referenziert wird
|
21004 |
AX_Verwaltung REFERENT |
haengtAn |
AX_Person REFERENZIERTES |
Prüfen, ob AX_Person andere Objekte referenziert oder von anderen Objekten referenziert wird
|
21005 |
AX_Vertretung REFERENT |
haengtAn |
AX_Person REFERENZIERTES |
Prüfen, ob AX_Person andere Objekte referenziert oder von anderen Objekten referenziert wird
|
21006 |
AX_Namensnummer REFERENZIERTES |
bestehtAusRechtsverhaeltnissenZu |
AX_Namensnummer |
Prüfen, ob AX_Namensnummer weitere AX_Namensnummer referenziert
|
21006 |
AX_Namensnummer |
hatVorgaenger |
AX_Namensnummer |
AX_Namensnummer (Vorgänger) löschen und gelöschte Objektart mit OID im Protokoll ausgeben. |
21006 |
AX_Namensnummer |
benennt |
AX_Person |
Prüfen, ob AX_Person noch anderweitig referenziert wird
|
21007 |
AX_Buchungsblatt |
istBestandteilVon |
AX_Namensnummer |
AX_Namensnummer löschen und gelöschte Objektart mit OID im Protokoll ausgeben.. |
21008 |
AX_Buchungsstelle |
an |
AX_Buchungsstelle |
AX_Buchungsstelle (Referent) löschen und gelöschte Objektart mit OID im Protokoll ausgeben. Da die Relation "an" mehrfach vorkommen kann, z.B. bei Gesamterbbaurecht, ist hier zunächst zu prüfen, ob weitere solche Referenzen vorhanden sind, bevor die implizite Löschung erfolgen kann. |
21008 |
AX_Buchungsstelle REFERENT |
wirdVerwaltetVon |
AX_Verwaltung REFERENZIERTES |
Prüfen, ob AX_Verwaltung andere Objekte referenziert oder von anderen Objekten referenziert wird
|
31001 |
AX_Gebaeude REFERENZIERTES |
zeigtAuf |
AX_Gebaeudeausgestaltung REFERENT |
AX_Gebaeudeausgestaltung löschen und gelöschte Objektart mit OID im Protokoll ausgeben. |
31001 |
AX_Gebaeude REFERENT |
hat |
AX_LagebezeichnungMitPseudonummer |
Prüfen, ob AX_LagebezeichnungMitPseudonummer noch anderweitig referenziert wird
|
31001 |
AX_Gebaeude REFERENT |
gehoert |
AX_Person REFERENZIERTES |
Prüfen, ob AX_Person andere Objekte referenziert oder von anderen Objekten referenziert wird
|
73011 |
AX_Dienststelle |
hat + |
AX_Anschrift |
Prüfen, ob AX_Anschrift von anderen AX_Person oder AX_Dienststelle referenziert wird
|
82001 |
AX_Benutzer |
gehoertZu |
AX_Benutzergruppe |
Prüfen, ob AX_Benutzergruppe von weiteren AX_Benutzer referenziert wird
|
82001 |
AX_Benutzer |
ist |
AX_Person |
Prüfen, ob AX_Person von anderen Objekten referenziert wird
|
A.2.4. Festlegungen für einzelne Relationen des ATKIS- Subschemas
Zu löschendes Objekt |
Betroffene Relation |
"Implizit" betroffene Objektart |
Aktion der Datenhaltungskomponente |
|
Objekt in Sp.1 wird gelöscht, wenn nichts anderes gesagt wird. |
Art des Mangels |
(D.h. was mit den Objekten in Spalte 3 bzw. der Referenz geschehen soll) |
||
Nr. |
Spalte 1 |
Spalte 2 |
Spalte 3 |
Spalte 4 |
42002 |
AX_Strasse |
bestehtAus |
AX_Fahrbahnachse |
Prüfung, ob AX_Strasse von anderen Objekten referenziert wird
|
42003 |
AX_Strassenachse |
istTeilVon |
AX_Strasse |
Prüfung, ob AX_Strasse von anderen Objekten referenziert wird
|
A.3. Implizite Funktionen im Führungsprozess für ein System zum Sekundärnachweis
Zu löschendes Objekt |
Betroffene Relation |
"Implizit" betroffene Objektart |
Aktion der Datenhaltungskomponente |
|
Objekt in Sp.1 wird gelöscht, wenn nichts anderes gesagt wird. |
Art des Mangels |
(D.h. was mit den Objekten in Spalte 3 bzw. der Referenz geschehen soll) |
||
Nr. |
Spalte 1 |
Spalte 2 |
Spalte 3 |
Spalte 4 |
a) |
Objekt A REFERENT |
… |
Objekt B REFERENZIERTES |
Wird Objekt A gelöscht, so werden mit ihm auch seine Referenzen, Überführungs- und Unterführungsrelationen gelöscht. |
b) |
Objekt A wird eingetragen REFERENT |
… Gegenreferenz fehlt |
Objekt B REFERENZIERTES |
|
c) |
Objekt A REFERENT |
… Referenz fehlt |
Objekt B REFERENZIERTES |
|
Sekundärnachweise können von verschiedenen Systemen mit sehr unterschiedlichen Fähigkeiten geführt werden. Implizite Fortführungen des Systems für den Primärnachweis, die über die von einem System für den Sekundärnachweis verlangten impliziten Funktionen hinausgehen, sind bei Abgabe der Fortführungsdaten über die NAS in explizite Fortführungen umzuwandeln. Dieser Forderung wird durch die Versionierung auch der im Primärnachweis implizit fortgeführten Objekte Rechnung getragen.